rfc9390xml2.original.xml   rfc9390.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY nbsp "&#160;">
C.2119.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY nbhy "&#8209;">
C.8174.xml"> <!ENTITY wj "&#8288;">
<!ENTITY RFC6733 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6733.xml">
<!ENTITY RFC7155 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7155.xml">
]> ]>
<rfc submissionType="IETF" docName="draft-ietf-dime-group-signaling-14" category <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
="std" ipr="trust200902"> std" consensus="true" docName="draft-ietf-dime-group-signaling-14" number="9390"
<!-- Generated by id2xml 1.5.0 on 2022-11-23T02:01:22Z --> ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs
<?rfc strict="yes"?> ="true" tocInclude="true" version="3">
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc toc="yes"?>
<front>
<title>Diameter Group Signaling</title>
<author initials="M." surname="Jones" fullname="Mark Jones">
<organization>Individual</organization>
<address><email>mark@azu.ca</email>
</address>
</author>
<author initials="M." surname="Liebsch" fullname="Marco Liebsch">
<organization abbrev="NEC">NEC Laboratories Europe GmbH</organization>
<address><postal><street>Kurfuersten-Anlage 36</street>
<city>Heidelberg</city>
<code>D-69115</code>
<country>Germany</country>
</postal>
<email>marco.liebsch@neclab.eu</email>
</address>
</author>
<author initials="L." surname="Morand" fullname="Lionel Morand">
<organization abbrev="Orange">Orange Labs</organization>
<address><postal><street>38/40 rue du General Leclerc</street>
<city>Issy-Les-Moulineaux Cedex 9</city>
<code>92794</code>
<country>France</country>
</postal>
<email>lionel.morand@orange.com</email>
</address>
</author>
<date year="2022" month="November"/>
<area>ops</area>
<workgroup>dime</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in the title)
for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract><t> <!-- xml2rfc v2v3 conversion 3.15.2 -->
<!-- Generated by id2xml 1.5.0 on 2022-11-23T02:01:22Z -->
<front>
<title>Diameter Group Signaling</title>
<seriesInfo name="RFC" value="9390"/>
<author initials="M." surname="Jones" fullname="Mark Jones">
<organization>Individual</organization>
<address>
<email>mark@azu.ca</email>
</address>
</author>
<author initials="M." surname="Liebsch" fullname="Marco Liebsch">
<organization abbrev="NEC">NEC Laboratories Europe GmbH</organization>
<address>
<postal>
<street>Kurfuersten-Anlage 36</street>
<city>Heidelberg</city>
<code>D-69115</code>
<country>Germany</country>
</postal>
<email>marco.liebsch@neclab.eu</email>
</address>
</author>
<author initials="L." surname="Morand" fullname="Lionel Morand">
<organization abbrev="Orange">Orange Labs</organization>
<address>
<postal>
<street>38/40 rue du General Leclerc</street>
<city>Issy-Les-Moulineaux Cedex 9</city>
<code>92794</code>
<country>France</country>
</postal>
<email>lionel.morand@orange.com</email>
</address>
</author>
<date year="2023" month="April"/>
<area>ops</area>
<workgroup>dime</workgroup>
<abstract>
<t>
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 bulk operations on all (or part of) the sessions managed by a enable 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.</t> signaling optimization.</t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="sect-1" numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction" anchor="sect-1"><t> <t>
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 many thousands of command exchanges to enforce the same operation in many thousands of command exchanges enforcing the same operation
on each session in the group. In order to reduce signaling, it would on 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 managed by a Diameter node using a single or a few command sessions managed by a Diameter node using a single or a few command
exchanges.</t> exchanges.</t>
<t>
<t>
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, applying Diameter commands, such as performing re-authentication,
re-authorization, termination and abortion of sessions to a group of re-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 any Instead, it defines mechanisms, commands, and Attribute-Value Pairs (AVPs) th at may be used by any
Diameter application that requires management of groups of sessions.</t> Diameter application that requires management of groups of sessions.</t>
<t>
<t>
These mechanisms take the following design goals and features into These mechanisms take the following design goals and features into
account: account:
<list style="symbols"> </t>
<ul spacing="normal">
<t>Minimal impact to existing applications</t> <li>minimal impact to existing applications</li>
<li>extension of existing commands' Command Code Format (CCF) with
<t>Extension of existing commands' Command Code Format (CCF) with optional AVPs to enable grouping and group operations</li>
optional AVPs to enable grouping and group operations</t> <li>fallback to single-session operation</li>
<li>implicit discovery of capability to support grouping and group
<t>Fallback to single session operation</t>
<t>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 a
Diameter peer's capability to support session grouping and session group Diameter peer's capability to support session grouping and session group
operations</t> operations</li>
</ul>
</list> </section>
</t> <section anchor="sect-2" numbered="true" toc="default">
</section> <name>Terminology</name>
<t>
<section title="Terminology" anchor="sect-2"><t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUI
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", RED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bc
"OPTIONAL" in this document are to be interpreted as described in BCP p14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described
y appear in all in BCP
14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="d
efault"/> when, and only when, they appear in all
capitals, as shown here.</t> capitals, as shown here.</t>
<t>
<t> This document uses terminology defined in <xref target="RFC6733" format="defa
This document uses terminology defined in <xref target="RFC6733"/>.</t> ult"/>.</t>
</section>
</section> <section anchor="sect-3" numbered="true" toc="default">
<name>Protocol Overview</name>
<section title="Protocol Overview" anchor="sect-3"><section title="Buildi <section anchor="sect-3.1" numbered="true" toc="default">
ng and Modifying Session Groups" anchor="sect-3.1"><t> <name>Building and Modifying Session Groups</name>
<t>
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.</t> sessions.</t>
<t>
<t> The client and the server can assign a new Diameter session to a group, e.g.,
Client and Server can assign a new Diameter session to a group, e.g.,
in case the subscription profile of the associated user has similar in case the subscription profile of the associated user has similar
characteristics as the profile of other users whose Diameter session characteristics as the profile of other users whose Diameter session
has been assigned to one or multiple groups. A single command can be has been assigned to one or multiple groups. A single command can be
issued and applied to all sessions associated with such group(s), issued and applied to all sessions associated with one or more such groups,
e.g., to adjust common profile or policy settings.</t> e.g., to adjust common profile or policy settings.</t>
<t>
<t>
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.</t> profile.</t>
<t>
<t>
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.</t> a different group, which is maintained at the new Diameter client.</t>
<t>
<t> 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 a
promotional period that applied to multiple subscriber profiles. 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.</t> these sessions to any other existing or new group.</t>
</section>
</section> <section anchor="sect-3.2" numbered="true" toc="default">
<name>Issuing Group Commands</name>
<section title="Issuing Group Commands" anchor="sect-3.2"><t> <t>
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 and
initiates the termination of all sessions associated with the 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.</t> identifier of the group.</t>
</section>
</section> <section anchor="sect-3.3" numbered="true" toc="default">
<name>Permission Considerations</name>
<section title="Permission Considerations" anchor="sect-3.3"><t> <t>
Permission considerations in the context of this draft apply to the Permission considerations in the context of this document apply to the
permission of Diameter nodes to build new session groups, to assign/ permission of Diameter nodes to build new session groups, to assign/remove
remove a session to/from a session group and to delete an existing a session to/from a session group, and to delete an existing
session group.</t> session group.</t>
<t>
<t> When a client or server decides to create a new session group,
When a client or a server decides to create a new session group, e.g., to group all sessions that share certain characteristics, this
e.g., to group all sessions which share certain characteristics, this
node builds a session group identifier according to the rules node builds a session group identifier according to the rules
described in <xref target="sect-7.3"/> and becomes the owner of the group.</t described in <xref target="sect-7.3" format="default"/> and becomes the owner
> of the group.</t>
<t>
<t>
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.</t> or server) that has assigned this session to the session group.</t>
<t>
<t>
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.</t> assigned to this session group.</t>
<t>
<t> Diameter applications with implicit support for session groups <bcp14>MAY</bc
Diameter applications with implicit support for session groups MAY p14>
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 from a group which is owned by the server. Details about session from a group that is owned by the server. Details about
enforcing a more constrained permission model are out of scope of enforcing a more constrained permission model are out of scope of
this specification.</t> this specification.</t>
</section>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default">
</section> <name>Protocol Description</name>
<section anchor="sect-4.1" numbered="true" toc="default">
<section title="Protocol Description" anchor="sect-4"><section title="Ses <name>Session Grouping Capability Discovery</name>
sion Grouping Capability Discovery" anchor="sect-4.1"><t> <t>
Diameter nodes SHOULD NOT perform group operations with peer nodes Diameter nodes <bcp14>SHOULD NOT</bcp14> perform group operations with peer n
odes
unless the node has advertised support for session grouping and group unless the node has advertised support for session grouping and group
operations.</t> operations.</t>
<section anchor="sect-4.1.1" numbered="true" toc="default">
<section title="Capability Discovery based on the Application Id" anchor= <name>Capability Discovery Based on the Application Id</name>
"sect-4.1.1"><t> <t>
Newly defined Diameter applications may natively support Diameter Newly defined Diameter applications may intrinsically support Diameter
session grouping and group operations. Such applications provide session grouping and group operations. In these cases, there is no need
intrinsic discovery for the support of session grouping capability of a specific discovery mechanism for the support of session grouping
using the assigned Application Id advertised during the capability capability besides the discovery of the Application Id assigned to the
exchange phase described in Section 5.3 of <xref target="RFC6733"/>.</t> application advertised during the capability exchange phase described in <xref
target="RFC6733" section="5.3" sectionFormat="of" format="default"/>.</t>
<t> <t>
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 <xref target="sect-4.1.2"/> can be omitted in Diameter messages being exch anged in <xref target="sect-4.1.2" format="default"/>, can be omitted in Diameter m essages being exchanged
between nodes.</t> between nodes.</t>
</section>
</section> <section anchor="sect-4.1.2" numbered="true" toc="default">
<name>Capability Discovery Based on AVP Presence</name>
<section title="Capability Discovery based on AVP Presence" anchor="sect- <t>
4.1.2"><t>
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 grouping Diameter nodes to learn about nodes' capability to support session grouping
and group commands for a given application, a Diameter node SHOULD append and group commands for a given application, a Diameter node <bcp14>SHOULD</bc p14> append
the Session-Group-Capability-Vector AVP to any Diameter application the Session-Group-Capability-Vector AVP to any Diameter application
messages exchanged with the other Diameter nodes to announce its capability messages exchanged with the other Diameter nodes to announce its capability
to support session grouping and session group operations for the advertised to support session grouping and session group operations for the advertised
application. Implementations following the specification as per this application. Implementations following the specification as per this
document MUST set the BASE_SESSION_GROUP_CAPABILITY flag of the document <bcp14>MUST</bcp14> set the BASE_SESSION_GROUP_CAPABILITY flag of th e
Session-Group-Capability-Vector AVP.</t> Session-Group-Capability-Vector AVP.</t>
<t>
<t>
When a Diameter node receives at least one Session-Group-Capability-Vector When a Diameter node receives at least one Session-Group-Capability-Vector
AVP from a node with the BASE_SESSION_GROUP_CAPABILITY flag set, the AVP from a node with the BASE_SESSION_GROUP_CAPABILITY flag set, the
receiving Diameter node discovers the supported session grouping capability receiving Diameter node discovers the supported session grouping capability
of the sending Diameter node for the advertised application and MUST cache of the sending Diameter node for the advertised application and <bcp14>MUST</ bcp14> cache
this information for the lifetime of the routing table entry associated this information for the lifetime of the routing table entry associated
with the peer identity/Application Id pair (see Section 2.7 of <xref target=" with the peer identity / Application Id pair (see <xref target="RFC6733" sect
RFC6733"/>).</t> ion="2.7" sectionFormat="of" format="default"/>).</t>
</section>
</section> </section>
<section anchor="sect-4.2" numbered="true" toc="default">
</section> <name>Session Grouping</name>
<t>
<section title="Session Grouping" anchor="sect-4.2"><t>
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 <bcp14>MUST</bcp14> maintain consistency of associated applicatio n
session states for these multiple session groups.</t> session states for these multiple session groups.</t>
<t>
<t>
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, Authorization, and Accounting (AAA) applications
typically assign the role of a "Diameter client" to the Diameter node typically assign the role of a "Diameter client" to the Diameter node
initiating the Diameter session and the role of "Diameter server" to initiating the Diameter session and the role of "Diameter server" to
the node authorizing the Diameter session. This specification does the node authorizing the Diameter session. This specification does
not restrict group creation, assignment or deletion actions to a 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. <xref target="sect-5"/> describes particularities abou t refer to either role. <xref target="sect-5" format="default"/> describes par ticularities about
session grouping and performing group commands when relay agents or session grouping and performing group commands when relay agents or
proxies are deployed.</t> proxies are deployed.</t>
<t>
<t>
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 <bcp14>MUST</bcp14> 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 individual
sessions being assigned to the group. Each Diameter node MUST also sessions being assigned to the group. Each Diameter node <bcp14>MUST</bcp14>
also
keep a record about sessions that it has assigned to a session group.</t> keep a record about sessions that it has assigned to a session group.</t>
<section anchor="sect-4.2.1" numbered="true" toc="default">
<section title="Group assignment at session initiation" anchor="sect-4.2. <name>Group Assignment at Session Initiation</name>
1"><t> <t>
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 Requirem
<xref target="RFC7155"/>, containing one or more session group identifiers. ents (NASREQ) AA-Request
Each of <xref target="RFC7155" format="default"/>, containing one or more session gro
these groups MUST be identified by a unique Session-Group-Id up identifiers. Each of
contained in a separate Session-Group-Info AVP as specified in these groups <bcp14>MUST</bcp14> be identified by a unique Session-Group-Id
<xref target="sect-7"/>.</t> contained in a separate Session-Group-Info AVP, as specified in
<xref target="sect-7" format="default"/>.</t>
<t> <t>
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 &lt;DiameterIdentity&gt; portion of the Session-Group-Id AVP itself in the &lt;DiameterIdentity&gt; portion of the Session-Group-Id AVP,
as per <xref target="sect-7.3"/>. For all assignments of a session to an act as per <xref target="sect-7.3" format="default"/>. For all assignments of a
ive 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, <bcp14>MUST</bcp14> 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.</t> has just been created or is still active.</t>
<t>
<t> The client <bcp14>MUST</bcp14> set the SESSION_GROUP_ALLOCATION_ACTION flag o
The client MUST set the SESSION_GROUP_ALLOCATION_ACTION flag of the f 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.</t> assigned to the identified session group.</t>
<t>
<t>
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 <bcp14>MUST</bcp14> include the Session-Group-Info AVP
the request including the Session-Group-Control-Vector AVP with the in
the request, including the Session-Group-Control-Vector AVP with the
SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP.</t> SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP.</t>
<t>
<t>
If the Diameter server receives a command request from a Diameter client If the Diameter server receives a command request from a Diameter client
and the command includes at least one Session-Group-Info AVP having the and the command includes at least one Session-Group-Info AVP with the
SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group-Control-Vector SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group-Control-Vector
AVP set, the server can accept or reject the request for group assignment. AVP set, the server can accept or reject the request for group assignment.
Reasons for rejection may be e.g., lack of resources for managing Reasons for rejection may be, e.g., lack of resources for managing
additional groups. When rejected, the session MUST NOT be assigned to any additional groups. When rejected, the session <bcp14>MUST NOT</bcp14> be ass
session group.</t> igned to any
session group.</t>
<t> <t>
If the Diameter server accepts the client's request for a group assignment, If the Diameter server accepts the client's request for a group
the server MUST assign the new session to each of the one or multiple assignment, the server <bcp14>MUST</bcp14> assign the new session to each (on
identified session groups when present in the Session-Group-Info AVP. If e or more)
of the identified session groups when present in the Session-
Group-Info AVP. If
one or multiple identified session groups are not already stored by the one or multiple identified session groups are not already stored by the
server, the server MUST store the newly identified group(s) to its local server, the server <bcp14>MUST</bcp14> store the one or more newly identified
list of known session groups. When sending the response to the client, groups to its local
e.g., a service-specific auth response as per NASREQ AA-Answer <xref target=" list of known session groups.
RFC7155"/>, When sending the response to the client,
the server MUST include all Session-Group-Info AVPs as received in the e.g., a service-specific authorization response, as per NASREQ AA-Answer <xre
f target="RFC7155" format="default"/>,
the server <bcp14>MUST</bcp14> include all Session-Group-Info AVPs received i
n the
client's request.</t> client's request.</t>
<t>
<t>
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 <bcp14>MUST</bcp 14>
add to the response the additional Session-Group-Info AVPs, each add 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 <bcp14>MUST</bcp14> have the SESSION_GROUP_ALLOCATION_ACTION flag set in the
Session-Group-Control-Vector AVP.</t> Session-Group-Control-Vector AVP.</t>
<t>
<t>
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 <xref target="RFC7155" service-specific authorization response, as per NASREQ AA-Answer <xref target
/>, and ="RFC7155" format="default"/>, and
MUST include all Session-Group-Info AVPs as received in the client's <bcp14>MUST</bcp14> include all Session-Group-Info AVPs received in the clien
t's
request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION
flag of the Session-Group-Control-Vector AVP. The server MAY still flag of the Session-Group-Control-Vector AVP. The server <bcp14>MAY</bcp14> still
accept the client's request for the identified session to proceed accept the client's request for the identified session to proceed
despite rejecting the group assignment. The response sent to the despite rejecting the group assignment. The response sent to the
client will then indicate success in the result code. In this case, client will then indicate success in the result code. In this case,
the session is treated as single session without assignment to any the session is treated as a single session without assignment to any
session group by the Diameter nodes.</t> session group by the Diameter nodes.</t>
<t>
<t>
If the assignment of the session to one or some of the multiple identified If the assignment of the session to one or some of the multiple identified
session groups fails, the session group assignment is treated as failure. session groups fails, the session group assignment is treated as a failure.
In such case the session is treated as single session without assignment to In such case, the session is treated as a single session without assignment t
o
any session group by the Diameter nodes. The server sends the response to any session group by the Diameter nodes. The server sends the response to
the client and MAY include those Session-Group-Info AVPs for which the the client and <bcp14>MAY</bcp14> include those Session-Group-Info AVPs for w hich the
group assignment failed. The SESSION_GROUP_ALLOCATION_ACTION flag of group assignment failed. The SESSION_GROUP_ALLOCATION_ACTION flag of
included Session-Group-Info AVPs MUST be cleared.</t> included Session-Group-Info AVPs <bcp14>MUST</bcp14> be cleared.</t>
<t>
<t>
If the Diameter server receives a command request from a Diameter client If the Diameter server receives a command request from a Diameter client
and the command includes a Session-Group-Info AVP which does not include a and the command includes a Session-Group-Info AVP that does not include a
Session-Group-Id AVP, the server MAY decide to assign the session to one or Session-Group-Id AVP, the server <bcp14>MAY</bcp14> decide to assign the sess
multiple session groups. For each session group, to which the server ion to one or
multiple session groups. For each session group to which the server
assigns the new session, the server includes a Session-Group-Info AVP with assigns the new session, the server includes a Session-Group-Info AVP with
the Session-Group-Id AVP identifying a session group in the response sent the Session-Group-Id AVP, identifying a session group in the response sent
to the client. Each of the Session-Group-Info AVPs included by the server to the client. Each of the Session-Group-Info AVPs included by the server
MUST have the SESSION_GROUP_ALLOCATION_ACTION flag of the <bcp14>MUST</bcp14> have the SESSION_GROUP_ALLOCATION_ACTION flag of the
Session-Group-Control-Vector AVP set.</t> Session-Group-Control-Vector AVP set.</t>
<t>
<t>
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 <bcp14>MUST NOT</bcp14> assign the new session to any session grou
treat the request as for a single session. The server MUST NOT p but
treat the request the same as for a single session. The server <bcp14>MUST N
OT</bcp14>
return any Session-Group-Info AVP in the command response.</t> return any Session-Group-Info AVP in the command response.</t>
<t>
<t>
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 of the associated Session-Group-Control-Vector AVP set, the flag of the associated Session-Group-Control-Vector AVP set, the
client MUST add the new session to all session groups as identified client <bcp14>MUST</bcp14> add the new session to all session groups as ident
in the one or multiple Session-Group-Info AVPs. If the Diameter ified
in one or multiple Session-Group-Info AVPs. If the Diameter
client fails to add the session to one or more session groups as client fails to add the session to one or more session groups as
identified in the one or multiple Session-Group-info AVPs, the client identified in one or multiple Session-Group-Info AVPs, the client
MUST terminate the session. The client MAY send a subsequent request <bcp14>MUST</bcp14> terminate the session. The client <bcp14>MAY</bcp14> sen
d a subsequent request
for session initiation to the server without requesting the for session initiation to the server without requesting the
assignment of the session to a session group.</t> assignment of the session to a session group.</t>
<t>
<t>
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 the SESSION_GROUP_ALLOCATION_ACTION flag of the associated have the SESSION_GROUP_ALLOCATION_ACTION flag of the associated
Session-Group-Control-Vector AVP cleared, the client MUST terminate Session-Group-Control-Vector AVP cleared, the client <bcp14>MUST</bcp14> term
the assignment of the session to the one or multiple groups. If the inate
the assignment of the session to one or multiple groups. If the
response from the server indicates success in the result code but response from the server indicates success in the result code but
only the assignment of the session to a session group has been only the assignment of the session to a session group has been
rejected by the server, the client treats the session as single rejected by the server, the client treats the session as a single
session without group assignment.</t> session without group assignment.</t>
<t>
<t>
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 <bcp14>MUST</bcp14> proceed as if the request was processed w
group assignments. The Diameter client MUST NOT retry to request ithout
group assignment for this session, but MAY try to request group group assignments. The Diameter client <bcp14>MUST NOT</bcp14> retry to requ
est
group assignment for this session but <bcp14>MAY</bcp14> try to request group
assignment for other new sessions.</t> assignment for other new sessions.</t>
</section>
</section> <section anchor="sect-4.2.2" numbered="true" toc="default">
<name>Removing a Session from a Session Group</name>
<section title="Removing a session from a session group" anchor="sect-4.2 <t>
.2"><t>
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 request session group, the client sends a service-specific re-authorization request
to the server and adds one Session-Group-Info AVP to the request for each to the server and adds one Session-Group-Info AVP to the request for each
session group, from which the client wants to remove the session. The session group from which the client wants to remove the session. The
session that is to be removed from a group is identified in the Session-Id session that is to be removed from a group is identified in the Session-Id
AVP of the command request. The SESSION_GROUP_ALLOCATION_ACTION flag of AVP of the command request. The SESSION_GROUP_ALLOCATION_ACTION flag of
the Session-Group-Control-Vector AVP in each Session-Group-Info AVP MUST be the Session-Group-Control-Vector AVP in each Session-Group-Info AVP <bcp14>MU ST</bcp14> be
cleared to indicate removal of the session from the session group cleared to indicate removal of the session from the session group
identified in the associated Session-Group-id AVP.</t> identified in the associated Session-Group-Id AVP.</t>
<t>
<t>
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.</t> it had been previously assigned.</t>
<t>
<t> If the Diameter server receives a request from the client that has at
If the Diameter server receives a request from the client which has 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 the SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server <bcp14>MUST</bcp14> remove the
session from the session group identified in the associated session from the session group identified in the associated
Session-Group-Id AVP. If the request includes at least one Session-Group-Id AVP. If the request includes at least one
Session-Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag
cleared and no Session-Id AVP present, the server MUST remove the session cleared and no Session-Id AVP present, the server <bcp14>MUST</bcp14> remove
the session
from all session groups to which the session has been previously assigned. from all session groups to which the session has been previously assigned.
The server MUST include in its response to the requesting client all The server <bcp14>MUST</bcp14> include in its response to the requesting clie
Session-Group-Id AVPs as received in the request.</t> nt all
Session-Group-Id AVPs received in the request.</t>
<t> <t>
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 to the client, indicating the session in the Session-Id AVP request to the client, indicating the session in the Session-Id AVP
of the request. The client sends a Re-Authorization Answer (RAA) or of the request. The client sends a Re-Auth-Answer (RAA) or
a service-specific answer to respond to the server's request. The a service-specific answer to respond to the server's request. The
client subsequently sends service-specific re-authorization request client 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 response to
the client, containing a list of Session-Group-Info AVPs with the the client, containing a list of Session-Group-Info AVPs with the
SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id
AVP identifying the session group, from which the session should be AVP identifying the session group from which the session should be
removed. The server MAY include to the service-specific auth removed. The server <bcp14>MAY</bcp14> include with the service-specific aut
horization
response a list of Session-Group-Info AVPs with the response a list of Session-Group-Info AVPs with the
SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP
identifying session groups to which the session remains subscribed. identifying session groups to which the session remains subscribed.
If the server decides to remove the identified session from all If the server decides to remove the identified session from all
session groups, to which the session has been previously assigned, session groups to which the session has been previously assigned,
the server includes in the service-specific auth response at least the server includes in the service-specific authorization response at least
one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION
flag cleared and Session-Group-Id AVP absent.</t> flag cleared and Session-Group-Id AVP absent.</t>
</section>
</section> <section anchor="sect-4.2.3" numbered="true" toc="default">
<name>Mid-session Group Assignment Modifications</name>
<section title="Mid-session group assignment modifications" anchor="sect- <t>
4.2.3"><t>
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.</t> permission considerations.</t>
<t>
<t>
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 one or service-specific re-authorization request to the server, containing one or
multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION
flag set and the Session-Group-Id AVP present, identifying the session flag set and the Session-Group-Id AVP present, identifying the session
group to which the session should be assigned. With the same message, the group to which the session should be assigned. With the same message, the
client MAY send one or multiple Session-Group-Info AVP with the client <bcp14>MAY</bcp14> send one or multiple Session-Group-Info AVPs with t he
SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP
identifying the session group from which the identified session is to be identifying the session group from which the identified session is to be
removed. To remove the session from all previously assigned session removed. To remove the session from all previously assigned session
groups, the client includes at least one Session-Group-Info AVP with the groups, the client includes at least one Session-Group-Info AVP with the
SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id AVP SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id AVP
present. When the server received the service-specific re-authorization present. When the server received the service-specific re-authorization
request, it MUST update its locally maintained view of the session groups request, it <bcp14>MUST</bcp14> update its locally maintained view of the ses sion groups
for the identified session according to the appended Session-Group-Info for the identified session according to the appended Session-Group-Info
AVPs. The server sends a service- specific auth response to the client AVPs. The server sends a service-specific authorization response to the clie nt
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 new session group to which the identified session has been identifying the new session group to which the identified session has been
assigned.</t> assigned.</t>
<t>
<t> When a Diameter server decides to update assigned groups mid-session, it
When a Diameter server decides to update assigned groups mid-session, it sends a Re-Auth-Request (RAR) message or a service-specific
sends a Re-Authorization Request (RAR) message or a service-specific request to the client identifying the session for which the session group
request to the client identifying the session, for which the session group lists are to be updated. The client responds with a Re-Auth-Answer (RAA)
lists are to be updated. The client responds with a Re-Authorization message or a service-specific answer. The client subsequently
Answer (RAA) message or a service-specific answer. The client subsequently
sends a service-specific re-authorization request containing one or sends a service-specific re-authorization request containing one or
multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION
flag set and the Session-Group-Id AVP identifying the session group to flag set and the Session-Group-Id AVP identifying the session group to
which the session had been previously assigned. The server responds with a which the session had been previously assigned. The server responds with a
service-specific auth response and includes one or multiple service-specific authorization response and includes one or multiple
Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set
and the Session-Group-Id AVP identifying the session group, to which the and the Session-Group-Id AVP identifying the session group to which the
identified session is to be assigned. With the same response message, the identified session is to be assigned. With the same response message, the
server MAY send one or multiple Session-Group-Info AVPs with the server <bcp14>MAY</bcp14> send one or multiple Session-Group-Info AVPs with t he
SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP
identifying the session groups from which the identified session is to be identifying the session groups from which the identified session is to be
removed. When a server wants to remove the session from all previously removed. When a server wants to remove the session from all previously
assigned session groups, it sends at least one Session- Group-Info AVP with assigned session groups, it sends at least one Session- Group-Info AVP with
the response having the SESSION_GROUP_ALLOCATION_ACTION flag cleared and no the response having the SESSION_GROUP_ALLOCATION_ACTION flag cleared and no
Session-Group-Id AVP present.</t> Session-Group-Id AVP present.</t>
</section>
</section> </section>
<section anchor="sect-4.3" numbered="true" toc="default">
</section> <name>Deleting a Session Group</name>
<t>
<section title="Deleting a Session Group" anchor="sect-4.3"><t>
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 the Session-Group-Id AVP identifying the session group, which is and the Session-Group-Id AVP identifying the session group that is
to be deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the to be deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the
associated Session-Group-Control-Vector AVP MUST be cleared.</t> associated Session-Group-Control-Vector AVP <bcp14>MUST</bcp14> be cleared.</
t>
<t> <t>
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.</t> after the last session has been removed from this session group.</t>
</section>
</section> <section anchor="sect-4.4" numbered="true" toc="default">
<name>Performing Group Operations</name>
<section title="Performing Group Operations" anchor="sect-4.4"><section t <section anchor="sect-4.4.1" numbered="true" toc="default">
itle="Sending Group Commands" anchor="sect-4.4.1"><t> <name>Sending Group Commands</name>
<t>
Either Diameter node (client or server) can request the recipient of a Either Diameter node (client or server) can request the recipient of a
request to process an associated command for all sessions assigned to one request to process an associated command for all sessions assigned to one
or multiple groups by identifying these groups in the request. The sender or multiple groups by identifying these groups in the request. The sender
of the request appends for each group, to which the command applies, a of the request appends for each group to which the command applies a
Session-Group-Info AVP including the Session-Group-Id AVP to identify the Session-Group-Info AVP including the Session-Group-Id AVP to identify the
associated session group. Both, the SESSION_GROUP_ALLOCATION_ACTION flag associated session group. Both the SESSION_GROUP_ALLOCATION_ACTION flag
as well as the SESSION_GROUP_STATUS flag MUST be set.</t> and the SESSION_GROUP_STATUS flag <bcp14>MUST</bcp14> be set.</t>
<t>
<t>
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 <bcp14>MUST</bcp14> identify one of the single sessio
which is assigned to at least one of the groups being identified in ns
that is assigned to at least one of the groups being identified in
the appended Session-Group-Id AVPs.</t> the appended Session-Group-Id AVPs.</t>
<t>
<t> The sender of the request <bcp14>MUST</bcp14> indicate to the receiver how mu
The sender of the request MUST indicate to the receiver how multiple ltiple
resulting transactions associated with a group command are to be treated by resulting transactions associated with a group command are to be treated by
appending a single instance of a Group-Response-Action AVP. For example, appending a single instance of a Group-Response-Action AVP.
when a server sends a Re-Authorization Request (RAR) or a service-specific For example, when a server sends a Re-Auth-Request (RAR) or a service-specifi
c
server-initiated request to the client, it indicates to the client to server-initiated request to the client, it indicates to the client to
follow the request according to one of three possible procedures. When the follow the request according to one of three possible procedures. When the
server sets the Group-Response-Action AVP to ALL_GROUPS (1), the client server sets the Group-Response-Action AVP to ALL_GROUPS (1), the client
sends a single RAR message for all identified groups. When the server sets sends a single RAR message for all identified groups. When the server sets
the Group-Response-Action AVP to PER_GROUP (2), the client sends a single the Group-Response-Action AVP to PER_GROUP (2), the client sends a single
RAR message for each identified group individually. When the server sets RAR message for each identified group individually. When the server sets
the Group-Response-Action AVP to PER_SESSION (3), the client follows-up the Group-Response-Action AVP to PER_SESSION (3), the client follows up
with a single RAR message per impacted session. If a session is included with a single RAR message per impacted session. If a session is included
in more than one of the identified session groups, the client sends only in more than one of the identified session groups, the client sends only
one RAR message for that session.</t> one RAR message for that session.</t>
<t>
<t>
If the sender sends a request including the Group-Response-Action AVP set 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 before 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 only be sent receiving one or more corresponding answers, as the answers will only be sent
back when the request is processed for all the sessions or all the session back when the request is processed for all the sessions or all the sessions
of a session group. If the processing of the request is delay-sensitive, of a session group. If the processing of the request is delay sensitive,
the sender SHOULD NOT set the Group-Response-Action AVP to ALL_GROUPS (1) the sender <bcp14>SHOULD NOT</bcp14> set the Group-Response-Action AVP to ALL
_GROUPS (1)
or PER_GROUP (2). If the answer can be sent before the complete process of or PER_GROUP (2). If the answer can be sent before the complete process of
the request for all the sessions or if the request timeout timer is high the request for all the sessions or if the request timeout timer is high
enough, the sender MAY set the Group-Response-Action AVP to ALL_GROUPS (1) enough, the sender <bcp14>MAY</bcp14> set the Group-Response-Action AVP to AL L_GROUPS (1)
or PER_GROUP (2).</t> or PER_GROUP (2).</t>
<t>
<t>
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 any group identifier, but identifies the relevant session in append any group identifier; it identifies only the relevant session in
the Session-Id AVP.</t> the Session-Id AVP.</t>
</section>
</section> <section anchor="sect-4.4.2" numbered="true" toc="default">
<name>Receiving Group Commands</name>
<section title="Receiving Group Commands" anchor="sect-4.4.2"><t> <t>
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 <bcp14>SHOULD</bcp14> process th
e
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 <bcp14>MUST< /bcp14>
process the associated command only once per session.</t> process the associated command only once per session.</t>
</section>
</section> <section anchor="sect-4.4.3" numbered="true" toc="default">
<name>Error Handling for Group Commands</name>
<section title="Error Handling for Group Commands" anchor="sect-4.4.3"><t <t>
>
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 <bcp14>MUST</bcp14> be returned to the source of th
request. In such case, the sender of the request MUST fall back to e
request. In such case, the sender of the request <bcp14>MUST</bcp14> fall ba
ck 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, <bcp14>MUST</bcp14> be deleted according to
procedure described in <xref target="sect-4.3"/>.</t> the
procedure described in <xref target="sect-4.3" format="default"/>.</t>
<t> <t>
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 response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per the response message <bcp14>SHOULD</bcp14> indicate DIAMETER_LIMITED_SUCCESS,
Section 7.1.2 of <xref target="RFC6733"/>.</t> as per
<xref target="RFC6733" section="7.1.2" sectionFormat="of" format="default"/>.
<t> </t>
In the case of limited success, the sessions, for which the <t>
processing of the group command failed, MUST be identified by In the case of limited success, the sessions for which the
including their Session-Id AVP in the Failed-AVP AVP as per processing of the group command failed <bcp14>MUST</bcp14> be identified by
Section 7.5 of <xref target="RFC6733"/>. The sender of the request MUST fall including their Session-Id AVP in the Failed-AVP AVP, as per
back <xref target="RFC6733" section="7.5" sectionFormat="of" format="default"/>.
to single-session operation for each of the identified sessions, for The sender of the request <bcp14>MUST</bcp14> fall back
to single-session operation for each of the identified sessions for
which the group command failed. In addition, each of these sessions which the group command failed. In addition, each of these sessions
MUST be removed from all session groups to which the group command <bcp14>MUST</bcp14> be removed from all session groups to which the group com mand
applied. To remove sessions from a session group, the Diameter applied. To remove sessions from a session group, the Diameter
client performs the procedure described in <xref target="sect-4.2.2"/>.</t> client performs the procedure described in <xref target="sect-4.2.2" format="
default"/>.</t>
</section> </section>
<section anchor="sect-4.4.4" numbered="true" toc="default">
<section title="Single-Session Fallback" anchor="sect-4.4.4"><t> <name>Single-Session Fallback</name>
Either Diameter node can fall back to single session operation by <t>
ignoring and omitting the optional group session-specific AVPs. Either Diameter node can fall back to single-session operation by
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 <bcp14>MUST
NOT identify any group but identify solely the single session for NOT</bcp14>
include any group identifier but only the Session-Id identifying the session
for
which the command has been processed.</t> which the command has been processed.</t>
</section>
</section> </section>
</section>
</section> <section anchor="sect-5" numbered="true" toc="default">
<name>Operation with Proxy Agents</name>
</section> <t>
<section title="Operation with Proxy Agents" anchor="sect-5"><t>
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 <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> update and maintain consis
local session states as per the result of the group commands which tency of its
local session states as per the result of the group commands that
are operated between a Diameter client and a server. In such case, are operated between a Diameter client and a server. In such case,
the Proxy Agent MUST act as a Diameter server in front of the the Proxy Agent <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> act as a Diameter client in front of
Diameter server. Therefore, the client and server behavior described the
in <xref target="sect-4"/> applies respectively to the stateful Proxy Agent.< Diameter server. Therefore, the client and the server behavior described
/t> in <xref target="sect-4" format="default"/> applies respectively to the state
ful Proxy Agent.</t>
<t> <t>
If a stateful Proxy Agent manipulates session groups, it MUST If a stateful Proxy Agent manipulates session groups, it <bcp14>MUST</bcp14>
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.</t> policies that apply to the client's domain and the server's domain.</t>
<t>
<t> Stateless Proxy Agents do not maintain any session states (only transaction
Stateless Proxy Agents do not maintain any session state (only transaction states are maintained). Consequently, the notion of a session group is
state are maintained). Consequently, the notion of session group is
transparent for any stateless Proxy Agent present between a Diameter client transparent for any stateless Proxy Agent present between a Diameter client
and a Diameter server handling session groups. Session group related AVPs and a Diameter server handling session groups. Session-group-related AVPs
being defined as optional AVP are ignored by stateless Proxy Agents and being defined as an optional AVP are ignored by stateless Proxy Agents and
should not be removed from the Diameter commands. If they are removed by should not be removed from the Diameter commands. If they are removed by
the Proxy Agent for any reason, the Diameter client and Diameter server the Proxy Agent for any reason, the Diameter client and Diameter server
will discover the absence the related session group AVPs and will fall back will discover the absence of the session-group-related AVPs and will fall bac
to single-session processing, as described in <xref target="sect-4"/>.</t> k
to single-session processing, as described in <xref target="sect-4" format="d
</section> efault"/>.</t>
</section>
<section title="Commands Formatting" anchor="sect-6"><t> <section anchor="sect-6" numbered="true" toc="default">
<name>Commands Formatting</name>
<t>
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 provided
by the Diameter Base protocol. This section provides the guidelines by the Diameter Base protocol. This section provides the guidelines
to extend the CCF of existing Diameter commands with optional AVPs to to extend the CCF of existing Diameter commands with optional AVPs to
enable the recipient of the command applying the command to all enable the recipient of the command to apply the command to all
sessions associated with the identified group(s).</t> sessions associated with the identified group or groups.</t>
<section anchor="sect-6.1" numbered="true" toc="default">
<section title="Formatting Example: Group Re-Auth-Request" anchor="sect-6 <name>Formatting Example: Group Re-Auth-Request</name>
.1"><t> <t>
A request for re-authentication of one or more groups of users is issued by 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 as a single appending one or multiple Session-Group-Id AVPs, as well as appending a singl
instance of a Group-Response-Action AVP to the Re-Auth-Request (RAR). The e
one or multiple Session-Group-Id AVP(s) identify the associated group(s) instance of a Group-Response-Action AVP to the Re-Auth-Request (RAR).
for which the group re-authentication has been requested. The One or multiple Session-Group-Id AVPs identify one or more associated groups
for which group re-authentication has been requested. The
Group-Response-Action AVP identifies the expected means to perform and Group-Response-Action AVP identifies the expected means to perform and
respond to the group command. The recipient of the group command initiates respond to the group command. The recipient of the group command initiates
re-authentication for all users associated with the identified group(s). re-authentication for all users associated with the identified group or group s.
Furthermore, the sender of the group re-authentication request appends a Furthermore, the sender of the group re-authentication request appends a
Group-Response-Action AVP to provide more information to the receiver of Group-Response-Action AVP to provide more information to the receiver of
the command about how to accomplish the group operation.</t> the command about how to accomplish the group operation.</t>
<t>
<t> The value of the mandatory Session-Id AVP <bcp14>MUST</bcp14> identify a sess
The value of the mandatory Session-Id AVP MUST identify a session ion
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.</t> the groups being identified in the appended Session-Group-Id AVPs.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
<RAR> ::= < Diameter Header: 258, REQ, PXY > <RAR> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id > < Session-Id >
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ Destination-Host } { Destination-Host }
{ Auth-Application-Id } { Auth-Application-Id }
{ Re-Auth-Request-Type } { Re-Auth-Request-Type }
[ User-Name ] [ User-Name ]
[ Origin-State-Id ] [ Origin-State-Id ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
[ Session-Group-Capability-Vector ] [ Session-Group-Capability-Vector ]
* [ Session-Group-Info ] * [ Session-Group-Info ]
[ Group-Response-Action ] [ Group-Response-Action ]
* [ AVP ] * [ AVP ]
]]></artwork> ]]></artwork>
</figure> </section>
</section> </section>
<section anchor="sect-7" numbered="true" toc="default">
</section> <name>Attribute-Value Pairs (AVPs)</name>
<section title="Attribute-Value-Pairs (AVP)" anchor="sect-7"><figure><art <table>
work><![CDATA[ <name>AVPs for the Diameter Group Signaling</name>
+--------------------+ <thead>
| AVP Flag rules | <tr>
+----+---+------+----+ <th>Attribute Name</th>
AVP | | |SHOULD|MUST| <th rowspan="2" colspan="1">AVP Code Value Type</th>
Attribute Name Code Value Type |MUST|MAY| NOT | NOT| <th rowspan="1" colspan="4">AVP Flag rules</th>
+-------------------------------------------------+----+---+------+----+ </tr>
|Session-Group-Info TBD1 Grouped | | P | | V | <tr>
|Session-Group-Control-Vector TBD2 Unsigned32 | | P | | V | <th></th>
|Session-Group-Id TBD3 UTF8String | | P | | V | <th><bcp14>MUST</bcp14></th>
|Group-Response-Action TBD4 Unsigned32 | | P | | V | <th><bcp14>MAY</bcp14></th>
|Session-Group-Capability-Vector TBD5 Unsigned32 | | P | | V | <th><bcp14>SHOULD NOT</bcp14></th>
+-------------------------------------------------+----+---+------+----+ <th><bcp14>MUST NOT</bcp14></th>
</tr>
</thead>
<tbody>
<tr>
<td>Session-Group-Info</td>
<td>671 Grouped</td>
<td></td>
<td>P</td>
<td></td>
<td>V</td>
</tr>
<tr>
<td>Session-Group-Control-Vector</td>
<td>672 Unsigned32</td>
<td></td>
<td>P</td>
<td></td>
<td>V</td>
</tr>
<tr>
<td>Session-Group-Id</td>
<td>673 UTF8String</td>
<td></td>
<td>P</td>
<td></td>
<td>V</td>
</tr>
<tr>
<td>Group-Response-Action</td>
<td>674 Unsigned32</td>
<td></td>
<td>P</td>
<td></td>
<td>V</td>
</tr>
<tr>
<td>Session-Group-Capability-Vector</td>
<td>675 Unsigned32</td>
<td></td>
<td>P</td>
<td></td>
<td>V</td>
</tr>
</tbody>
</table>
AVPs for the Diameter Group Signaling <section anchor="sect-7.1" numbered="true" toc="default">
]]></artwork> <name>Session-Group-Info AVP</name>
</figure> <t>
<section title="Session-Group-Info AVP" anchor="sect-7.1"><t> The Session-Group-Info AVP (AVP Code 671) is of type Grouped. It
The Session-Group-Info AVP (AVP Code TBD1) is of type Grouped. It contains the identifier of the session group, as well as an indication
contains the identifier of the session group as well as an indication
of the node responsible for session group identifier assignment.</t> of the node responsible for session group identifier assignment.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[ Session-Group-Info ::= < AVP Header: 671 >
Session-Group-Info ::= < AVP Header: TBD1 >
< Session-Group-Control-Vector > < Session-Group-Control-Vector >
[ Session-Group-Id ] [ Session-Group-Id ]
* [ AVP ] * [ AVP ]
]]></artwork> ]]></artwork>
</figure> </section>
</section> <section anchor="sect-7.2" numbered="true" toc="default">
<name>Session-Group-Control-Vector AVP</name>
<section title="Session-Group-Control-Vector AVP" anchor="sect-7.2"><t> <t>
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&lt;=x&lt;32) are allowed.< numeric values that are 2<sup>x</sup> (power of two, where 0&lt;=x&lt;32) are
/t> allowed.</t>
<t>
<t>
The following control flags are defined in this document:</t> The following control flags are defined in this document:</t>
<t>SESSION_GROUP_ALLOCATION_ACTION (0x00000001)
<t>SESSION_GROUP_ALLOCATION_ACTION (0x00000001) </t>
<ul empty="true" spacing="normal">
<list><t> <li>
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 by the Session-Group-Id AVP or the session's assignment identified by the Session-Group-Id AVP or the session's assignment
to the session group identified in the Session-Group-Id AVP is to the session group identified in the Session-Group-Id AVP is
still valid. When the flag is cleared, the identified Diameter still valid. When the flag is cleared, the identified Diameter
session is to be removed from at least one session group. When session is to be removed from at least one session group. When
the flag is cleared and the Session-Group-Info AVP identifies a the flag is cleared and the Session-Group-Info AVP identifies a
particular session group in the associated Session-Group-Id AVP, particular session group in the associated Session-Group-Id AVP,
the session is to be removed solely from the identified session the session is to be removed solely from the identified session
group. When the flag is cleared and the Session-Group-Info AVP group. When the flag is cleared and the Session-Group-Info AVP
does not identify a particular session group (Session-Group-Id AVP does not identify a particular session group (Session-Group-Id AVP
is absent), the identified Diameter session is to be removed from is absent), the identified Diameter session is to be removed from
all session groups to which it has been previously assigned. all session groups to which it has been previously assigned.
</t> </li>
</list></t> </ul>
<t>SESSION_GROUP_STATUS (0x00000010)
<t>SESSION_GROUP_STATUS (0x00000010)
<list><t> </t>
<ul empty="true" spacing="normal">
<li>
This flag indicates the status of the session group identified in the This flag indicates the status of the session group identified in the
associated Session-Group-Id AVP. The flag is set when the identified associated Session-Group-Id AVP. The flag is set when the identified
session group has just been created or is still active. If the flag is session group has just been created or is still active. If the flag is
cleared, the identified session group is deleted and the associated cleared, the identified session group is deleted and the associated
Session-Group-Id is released. If the Session-Group-Info AVP does not Session-Group-Id is released. If the Session-Group-Info AVP does not
include a Session-Group-Id AVP, this flag is meaningless and MUST be include a Session-Group-Id AVP, this flag is meaningless and <bcp14>MUST</ bcp14> be
ignored by the receiver. ignored by the receiver.
</t> </li>
</list></t> </ul>
</section>
</section> <section anchor="sect-7.3" numbered="true" toc="default">
<name>Session-Group-Id AVP</name>
<section title="Session-Group-Id AVP" anchor="sect-7.3"><t> <t>
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.</t> identifies a group of Diameter sessions.</t>
<t>
<t> The Session-Group-Id <bcp14>MUST</bcp14> be globally unique. The Session-Gro
The Session-Group-Id MUST be globally unique. The Session-Group-Id up-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 <bcp14>MUST</bcp14> beg in 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 <bcp14>MAY</b cp14>
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 <xref target="RFC6733"/>.</t> of the Session-Id AVP in <xref target="RFC6733" section="8.8" sectionFormat="
of" format="default"/>.</t>
</section> </section>
<section anchor="sect-7.4" numbered="true" toc="default">
<section title="Group-Response-Action AVP" anchor="sect-7.4"><t> <name>Group-Response-Action AVP</name>
The Group-Response-Action AVP (AVP Code TBD4) is of type Unsigned32 <t>
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 <bcp14>SHOULD</bcp14> 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:</t> defined by this document:</t>
<t>ALL_GROUPS (1)
<list> <dl newline="true">
<t>Follow up message exchanges associated with a group command should <dt>ALL_GROUPS (1)</dt>
<dd>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.</t> groups.</dd>
</list></t>
<t>PER_GROUP (2) <dt>PER_GROUP (2)</dt>
<list> <dd>Follow-up message exchanges associated with a group command should
<t>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.</t> group.</dd>
</list></t> <dt>PER_SESSION (3)</dt>
<dd>Follow-up message exchanges associated with a group command should
<t>PER_SESSION (3)
<list>
<t>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.</t> session.</dd>
</list> </t> </dl>
</section>
<section title="Session-Group-Capability-Vector AVP" anchor="sect-7.5"><t </section>
> <section anchor="sect-7.5" numbered="true" toc="default">
The Session-Group-Capability-Vector AVP (AVP Code TBD5) is of type <name>Session-Group-Capability-Vector AVP</name>
Unsigned32 and contains a 32-bit flags field to indicate capabilities <t>
The Session-Group-Capability-Vector AVP (AVP Code 675) is of type
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<sup>x</sup> (power of two, wher e
0&lt;=x&lt;32) are allowed. The value of (0) is reserved.</t> 0&lt;=x&lt;32) are allowed. The value of (0) is reserved.</t>
<t>
<t> The following capability is defined in this document:</t>
The following capabilities are defined in this document:</t> <t>BASE_SESSION_GROUP_CAPABILITY (0x00000001)
</t>
<t>BASE_SESSION_GROUP_CAPABILITY (0x00000001) <ul empty="true" spacing="normal">
<list> <li>This flag indicates the capability to support session grouping and
<t>This flag indicates the capability to support session grouping and session group operations according to this specification. </li>
session group operations according to this specification. </t> </ul>
</list> </section>
</t> </section>
<section anchor="sect-8" numbered="true" toc="default">
</section> <name>Result-Code AVP Values</name>
<t>
</section> This document does not define new Result-Code <xref target="RFC6733" format="
default"/> values for
<section title="Result-Code AVP Values" anchor="sect-8"><t>
This document does not define new Result-Code <xref target="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 support for group commands, may specify new Result-Codes.</t> intrinsic support for group commands, may specify new Result-Codes.</t>
</section>
</section> <section anchor="sect-9" numbered="true" toc="default">
<name>IANA Considerations</name>
<section title="IANA Considerations" anchor="sect-9"><t> <t>
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.</t> namespaces managed by IANA.</t>
<section anchor="sect-9.1" numbered="true" toc="default">
<name>AVP Codes</name>
<t>
IANA has registered the following new AVPs
from the "AVP Codes" registry defined in <xref target="RFC6733" format="defau
lt"/>. The AVPs are defined in <xref target="sect-7" format="default"/>.</t>
<section title="AVP Codes" anchor="sect-9.1"><t> <ul>
This specification requires IANA to register the following new AVPs <li>Session-Group-Info</li>
from the AVP Code namespace defined in <xref target="RFC6733"/>.</t> <li>Session-Group-Control-Vector</li>
<li>Session-Group-Id</li>
<t><list style="symbols"><t>Session-Group-Info</t> <li>Group-Response-Action</li>
<li>Session-Group-Capability-Vector</li>
<t>Session-Group-Control-Vector</t> </ul>
<t>Session-Group-Id</t>
<t>Group-Response-Action</t>
<t>Session-Group-Capability-Vector</t>
</list>
</t>
<t>
The AVPs are defined in <xref target="sect-7"/>.</t>
</section>
<section title="New Registries" anchor="sect-9.2"><t>
This specification requires IANA to create two registries:</t>
<t><list style="symbols"><t>Session-Group-Control-Vector AVP registry for
control bits with
two initial assignments, which are described in <xref target="sect-7.2"/>.
The
future registration assignment policy is proposed to be
Specification Required.</t>
<t>Session-Group-Capability-Vector AVP with one initial assignment,
which is described in <xref target="sect-7.5"/>. The future registration
assignment policy is proposed to be Standards Action.</t>
</list>
</t>
<t>
The AVP names can be used as registry names.</t>
</section>
</section>
<section title="Security Considerations" anchor="sect-10"><t> </section>
<section anchor="sect-9.2" numbered="true" toc="default">
<name>New Registries</name>
<t>
IANA has created the following two new registries.</t>
<ul spacing="normal">
<li>The "Session-Group-Control-Vector AVP Values (code 672)" registry
for control bits. Two initial assignments are described in <xref target="sect-7.
2" format="default"/>. The registration assignment policy is
Specification Required.</li>
<li>The "Session-Group-Capability-Vector AVP Values (code 675)" regist
ry. One initial assignment is described in <xref target="sect-7.5" format="defau
lt"/>. The registration
assignment policy is Standards Action.</li>
</ul>
</section>
</section>
<section anchor="sect-10" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
The security considerations of the Diameter protocol itself are discussed The security considerations of the Diameter protocol itself are discussed
in <xref target="RFC6733"/>. Use of the AVPs defined in this document MUST t ake into in <xref target="RFC6733" format="default"/>. Use of the AVPs defined in thi s document <bcp14>MUST</bcp14> take into
consideration the security issues and requirements of the Diameter base consideration the security issues and requirements of the Diameter base
protocol. In particular, the Session-Group-Info AVP (including the protocol. In particular, the Session-Group-Info AVP (including the
Session-Group-Control-Vector and the Session-Group-Id AVPs) should be Session-Group-Control-Vector and the Session-Group-Id AVPs) should be
considered as a security-sensitive AVPs in the same manner than the considered as a security-sensitive AVP in the same manner as the
Session-Id AVP in the Diameter base protocol <xref target="RFC6733"/>.</t> Session-Id AVP in the Diameter base protocol <xref target="RFC6733" format="d
efault"/>.</t>
<t> <t>
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.</t> limited set of commands using the session group management concept.</t>
<t>
<t> According to the Diameter base protocol <xref target="RFC6733" format="defaul
According to the Diameter base protocol <xref target="RFC6733"/>, transport t"/>, 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 mechanis
ms that are independent of
Diameter, such as IPsec. However, the lack of end-to-end security Diameter, such as IPsec. However, the lack of end-to-end security
features makes it difficult to establish trust in the session group features makes it difficult to establish trust in the session-group-related
related information received from non-adjacent nodes. Any Diameter information received from non-adjacent nodes. Any Diameter
agent in the message path can potentially modify the content of the agent in the message path can potentially modify the content of the
message and therefore the information sent by the Diameter client or message and therefore the information sent by the Diameter client or
the server. There is ongoing work on the specification of end-to-end the server. There is ongoing work on the specification of end-to-end
security features for Diameter. Such features would enable the security features for Diameter. Such features would enable the
establishment of trust relationship between non-adjacent nodes and establishment of a trust relationship between non-adjacent nodes, and
the security required for session group management would normally the security required for session group management would normally
rely on this end-to-end security. However, there is no assumption in rely on this end-to-end security. However, there is no assumption in
this document that such end-to-end security mechanism will be this document that such end-to-end security mechanism will be
available. It is only assumed that the solution defined on this available. It is only assumed that the solution defined on this
document relies on the security framework provided by the Diameter document relies on the security framework provided by the Diameter-based prot
based protocol.</t> ocol.</t>
<t>
<t> In some cases, a Diameter Proxy Agent can act on behalf of a client
In some cases, a Diameter Proxy agent can act on behalf of a client or a server. In such case, the security requirements that normally
or server. In such a case, the security requirements that normally apply to a client (or a server) apply equally to the Proxy Agent.</t>
apply to a client (or a server) apply equally to the Proxy agent.</t> </section>
</middle>
</section> <back>
<references>
<section title="Acknowledgments" anchor="sect-11"><t> <name>Normative References</name>
The authors of this document want to thank Ben Campbell and Eric <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
McMurry for their valuable comments to early versions of this draft. 9.xml"/>
Furthermore, authors thank Steve Donovan and Mark Bales for the <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
thorough review and comments on advanced versions of the WG document, 4.xml"/>
which helped a lot to improve this specification.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.673
3.xml"/>
</section> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.715
5.xml"/>
</middle> </references>
<section anchor="sect-a" numbered="true" toc="default">
<back> <name>Session Management -- Exemplary Session State Machine</name>
<references title="Normative References"> <section anchor="sect-a.1" numbered="true" toc="default">
&RFC2119; <name>Use of Groups for the Authorization Session State Machine</name>
&RFC8174; <t>
&RFC6733; <xref target="RFC6733" sectionFormat="of" section="8.1" format="default"/> de
&RFC7155; fines a set of finite state machines that
</references> represent the life cycle of Diameter sessions, which must be
<section title="Session Management -- Exemplary Session State Machine" an
chor="sect-a"><section title="Use of groups for the Authorization Session State
Machine" anchor="sect-a.1"><t>
Section 8.1 in <xref target="RFC6733"/> defines a set of finite state machine
s,
representing the life cycle of Diameter sessions, and which must be
observed by all Diameter implementations that make use of the observed by all Diameter implementations that make use of the
authentication and/or authorization portion of a Diameter authentication and/or authorization portion of a Diameter
application. This section defines, as example, additional state application. This section defines, for example, additional state
transitions related to the processing of the group commands which may transitions related to the processing of the group commands that may
impact multiple sessions.</t> impact multiple sessions.</t>
<t>
<t> The group membership is a session state, and therefore only those state
The group membership is session state and therefore only those state machines from <xref target="RFC6733" format="default"/> in which the server i
machines from <xref target="RFC6733"/> in which the server is maintaining ses s maintaining session
sion state are relevant in this document.
state are relevant in this document. As in <xref target="RFC6733"/>, the ter As in <xref target="RFC6733" format="default"/>, the term
m 'service-specific' below refers to a message defined in a Diameter
Service-Specific below refers to a message defined in a Diameter application (e.g., Mobile IPv4 or NASREQ).</t>
application (e.g., Mobile IPv4, NASREQ).</t> <t>
The following state machine is observed by a client when the state is
<t> maintained on the server. State transitions that are unmodified
The following state machine is observed by a client when state is from <xref target="RFC6733" format="default"/> are not repeated here.</t>
maintained on the server. State transitions which are unmodified <t>
from <xref target="RFC6733"/> are not repeated here.</t>
<t>
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 <xref target="sect-6.1"/>. Such Gr oup groups, has been exemplarily described in <xref target="sect-6.1" format="def ault"/>. 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 <xref target="RFC6733"/>.</t> notation applies to other commands, as per <xref target="RFC6733" format=
"default"/>.</t>
<figure><artwork><![CDATA[ <t>Additionally, the following acronyms are used in the tables below.</t>
CLIENT, STATEFUL <dl newline="false" spacing="normal">
State Event Action New State <dt>GASR:</dt>
--------------------------------------------------------------- <dd>Group-Abort-Session-Request</dd>
Idle Client or Device Requests Send Pending <dt>GASA:</dt>
access service <dd>Group-Abort-Session-Answer</dd>
specific <dt>GSTA:</dt>
auth req <dd>Group-Session-Termination-Answer</dd>
optionally <dt>GSTR:</dt>
including <dd>Group-Session-Termination-Request </dd>
groups </dl>
<table>
Open GASR received with Send GASA Discon <name>Group Authorization Session State Machine for Stateful Client</name>
Group-Response-Action with <thead>
= ALL_GROUPS, Result-Code <tr>
session is assigned to = SUCCESS, <th colspan="4">CLIENT, STATEFUL</th>
received group(s) and Send GSTR. </tr>
client will comply with <tr>
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 <th>State</th>
client will not comply with with <th>Event</th>
request to end all session Result-Code <th>Action</th>
in received group(s) != SUCCESS <th>New State</th>
</tr>
</thead>
<tbody>
<tr>
Discon GSTA Received Discon. Idle <td>Idle</td>
user/device <td>Client or Device Requests access</td>
<td> Send
service-specific
authorization req
optionally
including
groups</td>
<td>Pending</td>
</tr>
<tr>
Open GRAR received with Send GRAA, Pending <td>Open</td>
Group-Response-Action Send <td>GASR received with
= ALL_GROUPS, service Group-Response-Action
session is assigned to specific = ALL_GROUPS,
received group(s) and group session is assigned to
client will perform re-auth req received group(s) and
subsequent re-auth client will comply with
request to end the session</td>
<td>Send GASA
Result-Code
= SUCCESS,
Send GSTR</td>
<td>Discon</td>
</tr>
Open GRAR received with Send GRAA, Pending <tr>
Group-Response-Action Send <td>Open</td>
= PER_GROUP, service <td>GASR received with
session is assigned to specific Group-Response-Action
received group(s) and group = PER_GROUPS,
client will perform re-auth req session is assigned to
subsequent re-auth per group received group(s) and
client will comply with
request to end the session</td>
<td>Send GASA
with
Result-Code
= SUCCESS,
Send GSTR
per group</td>
<td>Discon</td>
</tr>
Open GRAR received with Send GRAA, Pending <tr>
Group-Response-Action Send <td>Open</td>
= PER_SESSION, service <td> GASR received with
session is assigned to specific Group-Response-Action
received group(s) and re-auth req = PER_SESSION,
client will perform per session session is assigned to
subsequent re-auth received group(s) and
client will comply with
request to end the session</td>
<td>Send GASA
with
Result-Code
= SUCCESS,
Send STR
per session</td>
<td>Discon</td>
</tr>
Open GRAR received and client will Send GRAA Idle <tr>
not perform subsequent with <td>Open</td>
re-auth Result-Code <td>GASR received,
!= SUCCESS, client will not comply with
Discon. request to end all sessions
user/device in received group(s)</td>
<td>Send GASA
with
Result-Code
!= SUCCESS</td>
<td>Open</td>
</tr>
Pending Successful service-specific Provide Open <tr>
group re-authorization answer service <td>Discon</td>
received. <td>GSTA received</td>
<td>Discon.
user/device</td>
<td>Idle</td>
</tr>
Pending Failed service-specific Discon. Idle <tr>
group re-authorization answer user/device <td>Open</td>
received.
]]></artwork>
</figure>
<t>
The following state machine is observed by a server when it is
maintaining state for the session. State transitions which are
unmodified from <xref target="RFC6733"/> are not repeated here.</t>
<figure><artwork><![CDATA[ <td>GRAR received with
SERVER, STATEFUL Group-Response-Action
State Event Action New State = ALL_GROUPS,
--------------------------------------------------------------- session is assigned to
received group(s) and
client will perform
subsequent re-auth</td>
<td>Send GRAA,
Send
service-specific
group
re-auth req</td>
<td>Pending</td>
</tr>
Idle Service-specific authorization Send Open <tr>
request received, and user successful <td>Open</td>
is authorized service <td>GRAR received with
specific Group-Response-Action
answer = PER_GROUP,
optionally session is assigned to
including received group(s) and
groups client will perform
subsequent re-auth </td>
<td>Send GRAA,
Send
service-specific
group
re-auth req
per group</td>
<td>Pending</td>
</tr>
Open Server wants to terminate Send GASR Discon <tr>
group(s) <td>Open</td>
<td>GRAR received with
Group-Response-Action
= PER_SESSION,
session is assigned to
received group(s) and
client will perform
subsequent re-auth</td>
<td>Send GRAA,
Send
service-specific
re-auth req
per session</td>
<td>Pending</td>
</tr>
Discon GASA received Cleanup Idle <tr>
<td>Open</td>
<td>GRAR received and client will
not perform subsequent
re-auth</td>
<td>Send GRAA
with
Result-Code
!= SUCCESS,
Discon.
user/device</td>
<td>Idle</td>
</tr>
Any GSTR received Send GSTA, Idle <tr>
Cleanup <td>Pending</td>
<td>Successful service-specific
group re-authorization answer
received</td>
<td>Provide
service</td>
<td>Open</td>
</tr>
Open Server wants to reauth Send GRAR Pending <tr>
group(s) <td>Pending</td>
<td>Failed service-specific
group re-authorization answer
received</td>
<td>Discon.
user/device</td>
<td>Idle</td>
</tr>
</tbody>
</table>
Pending GRAA received with Result-Code Update Open <t>
= SUCCESS session(s) The following state machine is observed by a server when it is
maintaining the state for the session. State transitions that are
unmodified from <xref target="RFC6733" format="default"/> are not repeated he
re.</t>
Pending GRAA received with Result-Code Cleanup Idle <table>
!= SUCCESS session(s) <name>Group Authorization Session State Machine for Stateful Server</name>
<thead>
<tr>
<th colspan="4">SERVER, STATEFUL</th>
</tr>
<tr>
Open Service-specific group Send Open <th>State</th>
re-authoization request successful <th>Event</th>
received and user is service <th>Action</th>
authorized specific <th>New State</th>
group </tr>
re-auth </thead>
answer
Open Service-specific group Send Idle <tbody>
re-authorization request failed <tr>
received and user is service <td>Idle</td>
not authorized specific <td>Service-specific authorization
group request received, and user
re-auth is authorized</td>
answer, <td>Send
cleanup successful
]]></artwork> service-specific
</figure> answer
</section> optionally
including
groups</td>
<td>Open</td>
</tr>
</section> <tr>
<td>Open</td>
<td>Server wants to terminate
group(s)</td>
<td>Send GASR</td>
<td>Discon</td>
</tr>
<tr>
<td>Discon</td>
<td>GASA received</td>
<td>Cleanup</td>
<td>Idle</td>
</tr>
</back> <tr>
<td>Any</td>
<td>GSTR received</td>
<td>Send GSTA, Cleanup</td>
<td>Idle</td>
</tr>
</rfc> <tr>
<td>Open</td>
<td>Server wants to reauth
group(s)</td>
<td>Send GRAR</td>
<td>Pending</td>
</tr>
<tr>
<td>Pending</td>
<td>GRAA received with Result-Code
= SUCCESS</td>
<td>Update session(s)</td>
<td>Open</td>
</tr>
<tr>
<td>Pending</td>
<td>GRAA received with Result-Code
!= SUCCESS</td>
<td>Cleanup session(s)</td>
<td>Idle</td>
</tr>
<tr>
<td>Open</td>
<td>Service-specific group
re-authorization request
received and user is
authorized</td>
<td>Send
successful
service-specific
group
re-auth
answer</td>
<td>Open</td>
</tr>
<tr>
<td>Open</td>
<td>Service-specific group
re-authorization request
received and user is
not authorized</td>
<td>Send
failed
service-specific
group
re-auth
answer,
Cleanup</td>
<td>Idle</td>
</tr>
</tbody>
</table>
</section>
</section>
<section anchor="sect-11" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
The authors of this document want to thank <contact fullname="Ben Campbell"/>
and <contact fullname="Eric
McMurry"/> for their valuable comments to early draft versions of this docume
nt.
Furthermore, the authors thank <contact fullname="Steve Donovan"/> and <conta
ct fullname="Mark Bales"/> for the
thorough review and comments on advanced versions of the WG document,
which helped a lot to improve this specification.</t>
</section>
</back>
</rfc>
 End of changes. 205 change blocks. 
824 lines changed or deleted 943 lines changed or added

This html diff was produced by rfcdiff 1.48.