<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
  <!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> zwsp   "&#8203;">
  <!ENTITY RFC6733 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6733.xml"> nbhy   "&#8209;">
  <!ENTITY RFC7155 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7155.xml"> wj     "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-ietf-dime-group-signaling-14" category="std" ipr="trust200902"> consensus="true" docName="draft-ietf-dime-group-signaling-14" number="9390" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.15.2 -->
  <!-- Generated by id2xml 1.5.0 on 2022-11-23T02:01:22Z -->
	<?rfc strict="yes"?>
	<?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>
    <seriesInfo name="RFC" value="9390"/>
    <author initials="M." surname="Jones" fullname="Mark Jones">
      <organization>Individual</organization>
	<address><email>mark@azu.ca</email>
      <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
      <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
      <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"/> year="2023" month="April"/>
    <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>
    <abstract>
      <t>
   In large network deployments, a single Diameter node can support over
   a million concurrent Diameter sessions.  In some use cases, Diameter
   nodes need to apply the same operation to a large group of Diameter
   sessions concurrently.  The Diameter base protocol commands operate
   on a single session so these use cases could can result in many thousands
   of command exchanges to enforce enforcing the same operation on each session in
   the group.  In order to reduce signaling, it would be is desirable to
   enable bulk operations on all (or part of) the sessions managed by a
   Diameter node using a single or a few command exchanges.  This
   document specifies the Diameter protocol extensions to achieve this
   signaling optimization.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sect-1"><t> anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   In large network deployments, a single Diameter node can support over
   a million concurrent Diameter sessions.  In some use cases, Diameter
   nodes need to apply the same operation to a large group of Diameter
   sessions concurrently.  For example, a policy decision point may need
   to modify the authorized quality of service for all active users
   having the same type of subscription.  The Diameter base protocol
   commands operate on a single session so these use cases could can result
   in many thousands of command exchanges to enforce enforcing the same operation
   on each session in the group.  In order to reduce signaling, it would
   be is
   desirable to enable bulk operations on all (or part of) the
   sessions managed by a Diameter node using a single or a few command
   exchanges.</t>
      <t>
   This document describes mechanisms for grouping Diameter sessions and
   applying Diameter commands, such as performing re-authentication,
   re-authorization, termination termination, and abortion of sessions to a group of
   sessions.  This document does not define a new Diameter application.
   Instead
   Instead, it defines mechanisms, commands commands, and AVPs Attribute-Value Pairs (AVPs) that may be used by any
   Diameter application that requires management of groups of sessions.</t>
      <t>
   These mechanisms take the following design goals and features into
   account:

   <list style="symbols">

     <t>Minimal

      </t>
      <ul spacing="normal">
        <li>minimal impact to existing applications</t>

     <t>Extension applications</li>
        <li>extension of existing commands' Command Code Format (CCF) with
     optional AVPs to enable grouping and group operations</t>

     <t>Fallback operations</li>
        <li>fallback to single session operation</t>

     <t>Implicit single-session operation</li>
        <li>implicit discovery of capability to support grouping and group
     operations in case no external mechanism is available to discover a
     Diameter peer's capability to support session grouping and session group
     operations</t>

   </list>
	</t>
     operations</li>
      </ul>
    </section>
    <section title="Terminology" anchor="sect-2"><t> anchor="sect-2" numbered="true" toc="default">
      <name>Terminology</name>
      <t>
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
   "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
   "OPTIONAL"
   "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP
   14 <xref target="RFC2119"/> target="RFC2119" format="default"/> <xref target="RFC8174"/> target="RFC8174" format="default"/> when, and only when, they appear in all
   capitals, as shown here.</t>
      <t>
   This document uses terminology defined in <xref target="RFC6733"/>.</t> target="RFC6733" format="default"/>.</t>
    </section>
    <section title="Protocol Overview" anchor="sect-3"><section title="Building anchor="sect-3" numbered="true" toc="default">
      <name>Protocol Overview</name>
      <section anchor="sect-3.1" numbered="true" toc="default">
        <name>Building and Modifying Session Groups" anchor="sect-3.1"><t> Groups</name>
        <t>
   In order to accommodate bulk operations on Diameter sessions, the
   concept of session groups is introduced.  Once sessions are added to
   a group, a command acting on the group will affect all the member
   sessions.</t>
        <t>
   Client
   The client and Server the server can assign a new Diameter session to a group, e.g.,
   in case the subscription profile of the associated user has similar
   characteristics as the profile of other users whose Diameter session
   has been assigned to one or multiple groups.  A single command can be
   issued and applied to all sessions associated with one or more such group(s), groups,
   e.g., to adjust common profile or policy settings.</t>
        <t>
   The assignment of a Diameter session to a group can be changed during
   an ongoing session (mid-session).  For example, if a user's
   subscription profile changes mid-session, a Diameter server may
   remove a session from an existing group and assign this session to a
   different group that is more appropriate for the new subscription
   profile.</t>
        <t>
   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
   a different group, which is maintained at the new Diameter client.</t>
        <t>
   It may be required to delete a session group, e.g. e.g., at the expiry of a
   promotional period that applied to multiple subscriber profiles.
   Deletion of such group requires subsequent individual treatment of
   each of the assigned sessions.  A node may decide to assign some of
   these sessions to any other existing or new group.</t>
      </section>
      <section title="Issuing anchor="sect-3.2" numbered="true" toc="default">
        <name>Issuing Group Commands" anchor="sect-3.2"><t> Commands</name>
        <t>
   Changes in the network condition may result in the Diameter server's
   decision to close all sessions in a given group.  As  For example, the
   server issues a single Session Termination Request (STR) command,
   including the identifier of the group of sessions which that are to be
   terminated.  The Diameter client treats the STR as a group command and
   initiates the termination of all sessions associated with the
   identified group.  Subsequently, the client confirms the successful
   termination of these sessions to the server by sending a single
   Session Termination Answer (STA) command, which includes the
   identifier of the group.</t>
      </section>
      <section title="Permission Considerations" anchor="sect-3.3"><t> anchor="sect-3.3" numbered="true" toc="default">
        <name>Permission Considerations</name>
        <t>
   Permission considerations in the context of this draft document apply to the
   permission of Diameter nodes to build new session groups, to assign/
   remove assign/remove
   a session to/from a session group group, and to delete an existing
   session group.</t>
        <t>
   When a client or a server decides to create a new session group,
   e.g., to group all sessions which that share certain characteristics, this
   node builds a session group identifier according to the rules
   described in <xref target="sect-7.3"/> target="sect-7.3" format="default"/> and becomes the owner of the group.</t>
        <t>
   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
   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>
        <t>
   A session group can only be deleted by the owner of the session
   group, resulting in individual treatment of the sessions that were
   assigned to this session group.</t>
        <t>
   Diameter applications with implicit support for session groups MAY <bcp14>MAY</bcp14>
   define a more constrained permission model.  For example, a more
   constrained model could require that a client must not remove a
   session from a group which that is owned by the server.  Details about
   enforcing a more constrained permission model are out of scope of
   this specification.</t>
      </section>
    </section>
    <section title="Protocol Description" anchor="sect-4"><section title="Session anchor="sect-4" numbered="true" toc="default">
      <name>Protocol Description</name>
      <section anchor="sect-4.1" numbered="true" toc="default">
        <name>Session Grouping Capability Discovery" anchor="sect-4.1"><t> Discovery</name>
        <t>
   Diameter nodes SHOULD NOT <bcp14>SHOULD NOT</bcp14> perform group operations with peer nodes
   unless the node has advertised support for session grouping and group
   operations.</t>
        <section title="Capability anchor="sect-4.1.1" numbered="true" toc="default">
          <name>Capability Discovery based Based on the Application Id" anchor="sect-4.1.1"><t> Id</name>
          <t>
   Newly defined Diameter applications may natively intrinsically support Diameter
   session grouping and group operations.  Such applications provide
   intrinsic In these cases, there is no need
  of a specific discovery mechanism for the support of session grouping
  capability
   using besides the discovery of the assigned Application Id assigned to the
  application advertised during the capability exchange phase described in Section 5.3 of <xref target="RFC6733"/>.</t> target="RFC6733" section="5.3" sectionFormat="of" format="default"/>.</t>
          <t>
   System-
   System-specific and deployment-specific means, as well as out-of-band
   mechanisms for capability discovery discovery, can be used to announce nodes'
   support for session grouping and session group operations.  In such
   case, the optional Session-Group-Capability-Vector AVP, as described
   in <xref target="sect-4.1.2"/> target="sect-4.1.2" format="default"/>, can be omitted in Diameter messages being exchanged
   between nodes.</t>
        </section>
        <section title="Capability anchor="sect-4.1.2" numbered="true" toc="default">
          <name>Capability Discovery based Based on AVP Presence" anchor="sect-4.1.2"><t> Presence</name>
          <t>
   If no other mechanism for capability discovery is deployed to enable
   Diameter nodes to learn about nodes' capability to support session grouping
   and group commands for a given application, a Diameter node SHOULD <bcp14>SHOULD</bcp14> append
   the Session-Group-Capability-Vector AVP to any Diameter application
   messages exchanged with the other Diameter nodes to announce its capability
   to support session grouping and session group operations for the advertised
   application.  Implementations following the specification as per this
   document MUST <bcp14>MUST</bcp14> set the BASE_SESSION_GROUP_CAPABILITY flag of the
   Session-Group-Capability-Vector AVP.</t>
          <t>
   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
   receiving Diameter node discovers the supported session grouping capability
   of the sending Diameter node for the advertised application and MUST <bcp14>MUST</bcp14> cache
   this information for the lifetime of the routing table entry associated
   with the peer identity/Application identity / Application Id pair (see Section 2.7 of <xref target="RFC6733"/>).</t> target="RFC6733" section="2.7" sectionFormat="of" format="default"/>).</t>
        </section>
      </section>
      <section title="Session Grouping" anchor="sect-4.2"><t> anchor="sect-4.2" numbered="true" toc="default">
        <name>Session Grouping</name>
        <t>
   This specification does not limit the number of session groups to
   which a single session is assigned.  It is left to the implementation
   of an application to determine such limitations.  If an application
   facilitates a session to belong to multiple session groups, the
   application MUST <bcp14>MUST</bcp14> maintain consistency of associated application
   session states for these multiple session groups.</t>
        <t>
   Either Diameter node (client or server) can initiate the assignment
   of a session to a single or multiple session groups.  Modification of
   a group by removing or adding a single or multiple user sessions can
   be initiated and performed mid-session by either Diameter node
   responsible for the session assignment to this group.  Although
   Diameter is a peer-to-peer protocol, Diameter AAA Authentication, Authorization, and Accounting (AAA) applications
   typically assign the role of a "Diameter client" to the Diameter node
   initiating the Diameter session and the role of "Diameter server" to
   the node authorizing the Diameter session.  This specification does
   not restrict group creation, assignment assignment, or deletion actions to a
   specific role.  In the following sections, "Diameter node" is used to
   refer to either role.  <xref target="sect-5"/> target="sect-5" format="default"/> describes particularities about
   session grouping and performing group commands when relay agents or
   proxies are deployed.</t>
        <t>
   Any Diameter node that has advertised support of session grouping and
   group operations MUST <bcp14>MUST</bcp14> store and maintain the group assignment as part
   of the session's state.  A list of all known session groups is
   locally maintained on each node, with each group pointing to individual
   sessions being assigned to the group.  Each Diameter node MUST <bcp14>MUST</bcp14> also
   keep a record about sessions that it has assigned to a session group.</t>
        <section title="Group assignment anchor="sect-4.2.1" numbered="true" toc="default">
          <name>Group Assignment at session initiation" anchor="sect-4.2.1"><t> Session Initiation</name>
          <t>
   To assign a session to a group at session initiation, a Diameter
   client sends a service specific service-specific request, e.g., NASREQ Network Access Server Requirements (NASREQ) AA-Request
   <xref target="RFC7155"/>, target="RFC7155" format="default"/>, containing one or more session group identifiers.  Each of
   these groups MUST <bcp14>MUST</bcp14> be identified by a unique Session-Group-Id
   contained in a separate Session-Group-Info AVP AVP, as specified in
   <xref target="sect-7"/>.</t> target="sect-7" format="default"/>.</t>
          <t>
   The client may choose one or multiple session groups from a list of
   existing session groups.  Alternatively, the client may decide to
   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 AVP,
   as per <xref target="sect-7.3"/>. target="sect-7.3" format="default"/>.  For all assignments of a session to an active
   session group made by the client or the server, the
   SESSION_GROUP_STATUS flag in the Session-Group-Info AVP, which
   identifies the session group, MUST <bcp14>MUST</bcp14> be set.  A set
   SESSION_GROUP_STATUS flag indicates that the identified session group
   has just been created or is still active.</t>
          <t>
   The client MUST <bcp14>MUST</bcp14> set the SESSION_GROUP_ALLOCATION_ACTION flag of the
   Session-Group-Control-Vector AVP in each appended Session-Group-Info
   AVP to indicate that the session contained in the request should be
   assigned to the identified session group.</t>
          <t>
   The client may also indicate in the request that it supports
   assignment of the session to one or more groups by the server.  In
   such a case, the client MUST <bcp14>MUST</bcp14> include the Session-Group-Info AVP in
   the request request, including the Session-Group-Control-Vector AVP with the
   SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP.</t>
          <t>
   If the Diameter server receives a command request from a Diameter client
   and the command includes at least one Session-Group-Info AVP having with the
   SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group-Control-Vector
   AVP set, the server can accept or reject the request for group assignment.
   Reasons for rejection may be be, e.g., lack of resources for managing
   additional groups.  When rejected, the session MUST NOT <bcp14>MUST NOT</bcp14> be assigned to any
	  session group.</t>
          <t>
   If the Diameter server accepts the client's request for a group
   assignment, the server MUST <bcp14>MUST</bcp14> assign the new session to each (one or more)
   of the one or multiple identified session groups when present in the Session-Group-Info Session-
   Group-Info AVP. If
   one or multiple identified session groups are not already stored by the
   server, the server MUST <bcp14>MUST</bcp14> store the one or more newly identified group(s) groups to its local
   list of known session groups.
   When sending the response to the client,
   e.g., a service-specific auth response authorization response, as per NASREQ AA-Answer <xref target="RFC7155"/>, target="RFC7155" format="default"/>,
   the server MUST <bcp14>MUST</bcp14> include all Session-Group-Info AVPs as received in the
   client's request.</t>
          <t>
   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
   one or multiple additional groups.  In such a case, the server MUST <bcp14>MUST</bcp14>
   add to the response the additional Session-Group-Info AVPs, each
   identifying a session group to which the new session is assigned by
   the server.  Each of the Session-Group-Info AVP AVPs added by the server
   MUST
   <bcp14>MUST</bcp14> have the SESSION_GROUP_ALLOCATION_ACTION flag set in the
   Session-Group-Control-Vector AVP.</t>
          <t>
   If the Diameter server rejects the client's request for a group
   assignment, the server sends the response to the client, e.g., a
   service-specific auth response authorization response, as per NASREQ AA-Answer <xref target="RFC7155"/>, target="RFC7155" format="default"/>, and
   MUST
   <bcp14>MUST</bcp14> include all Session-Group-Info AVPs as received in the client's
   request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION
   flag of the Session-Group-Control-Vector AVP.  The server MAY <bcp14>MAY</bcp14> still
   accept the client's request for the identified session to proceed
   despite rejecting the group assignment.  The response sent to the
   client will then indicate success in the result code.  In this case,
   the session is treated as a single session without assignment to any
   session group by the Diameter nodes.</t>
          <t>
   If the assignment of the session to one or some of the multiple identified
   session groups fails, the session group assignment is treated as a failure.
   In such case case, the session is treated as a single session without assignment to
   any session group by the Diameter nodes.  The server sends the response to
   the client and MAY <bcp14>MAY</bcp14> include those Session-Group-Info AVPs for which the
   group assignment failed.  The SESSION_GROUP_ALLOCATION_ACTION flag of
   included Session-Group-Info AVPs MUST <bcp14>MUST</bcp14> be cleared.</t>
          <t>
   If the Diameter server receives a command request from a Diameter client
   and the command includes a Session-Group-Info AVP which that does not include a
   Session-Group-Id AVP, the server MAY <bcp14>MAY</bcp14> decide to assign the session to one or
   multiple session groups.  For each session group, group to which the server
   assigns the new session, the server includes a Session-Group-Info AVP with
   the Session-Group-Id AVP AVP, identifying a session group in the response sent
   to the client.  Each of the Session-Group-Info AVPs included by the server
   MUST
   <bcp14>MUST</bcp14> have the SESSION_GROUP_ALLOCATION_ACTION flag of the
   Session-Group-Control-Vector AVP set.</t>
          <t>
   If the Diameter server receives a command request from a Diameter
   client and the command does not contain any Session-Group-Info AVP, AVPs,
   the server MUST NOT <bcp14>MUST NOT</bcp14> assign the new session to any session group but
   treat the request the same as for a single session.  The server MUST NOT <bcp14>MUST NOT</bcp14>
   return any Session-Group-Info AVP in the command response.</t>
          <t>
   If the Diameter client receives a response to its previously issued
   request from the server and the response includes at least one
   Session-Group-Info AVP having with the SESSION_GROUP_ALLOCATION_ACTION
   flag of the associated Session-Group-Control-Vector AVP set, the
   client MUST <bcp14>MUST</bcp14> add the new session to all session groups as identified
   in the one or multiple Session-Group-Info AVPs.  If the Diameter
   client fails to add the session to one or more session groups as
   identified in the one or multiple Session-Group-info Session-Group-Info AVPs, the client
   MUST
   <bcp14>MUST</bcp14> terminate the session.  The client MAY <bcp14>MAY</bcp14> send a subsequent request
   for session initiation to the server without requesting the
   assignment of the session to a session group.</t>
          <t>
   If the Diameter client receives a response to its previously issued
   request from the server and the one or more Session-Group-Info AVPs
   have the SESSION_GROUP_ALLOCATION_ACTION flag of the associated
   Session-Group-Control-Vector AVP cleared, the client MUST <bcp14>MUST</bcp14> terminate
   the assignment of the session to the one or multiple groups.  If the
   response from the server indicates success in the result code but
   only the assignment of the session to a session group has been
   rejected by the server, the client treats the session as a single
   session without group assignment.</t>
          <t>
   If a Diameter client sends a request for session initiation
   containing one or more Session-Group-Info AVPs but the response from
   the Diameter server does not contain a Session-Group-Info AVP, the
   Diameter client MUST <bcp14>MUST</bcp14> proceed as if the request was processed without
   group assignments.  The Diameter client MUST NOT <bcp14>MUST NOT</bcp14> retry to request
   group assignment for this session, session but MAY <bcp14>MAY</bcp14> try to request group
   assignment for other new sessions.</t>
        </section>
        <section title="Removing anchor="sect-4.2.2" numbered="true" toc="default">
          <name>Removing a session Session from a session group" anchor="sect-4.2.2"><t> Session Group</name>
          <t>
   When a Diameter client decides to remove a session from a particular
   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
   session group, 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
   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 <bcp14>MUST</bcp14> be
   cleared to indicate removal of the session from the session group
   identified in the associated Session-Group-id Session-Group-Id AVP.</t>
          <t>
   When a Diameter client decides to remove a session from all session
   groups to which the session has been previously assigned, the client
   sends a service-specific re-authorization request to the server and
   adds a single Session-Group-Info AVP to the request which that has the
   SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id
   AVP omitted.  The Session-Id AVP in the re-authorization request
   identifies the session that is to be removed from all groups to which
   it had been previously assigned.</t>
          <t>
   If the Diameter server receives a request from the client which that has at
   least one Session-Group-Info AVP appended with the
   SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server MUST <bcp14>MUST</bcp14> remove the
   session from the session group identified in the associated
   Session-Group-Id AVP.  If the request includes at least one
   Session-Group-info
   Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag
   cleared and no Session-Id AVP present, the server MUST <bcp14>MUST</bcp14> remove the session
   from all session groups to which the session has been previously assigned.
   The server MUST <bcp14>MUST</bcp14> include in its response to the requesting client all
   Session-Group-Id AVPs as received in the request.</t>
   <t>
     When the Diameter server decides to remove a session from one or
     multiple particular session groups or from all session groups to
     which the session has been assigned beforehand, the server sends a
   Re-Authorization Request
     Re-Auth-Request (RAR) or a service-specific server-initiated
     request to the client, indicating the session in the Session-Id AVP
     of the request. The client sends a Re-Authorization Answer Re-Auth-Answer (RAA) or
     a service-specific answer to respond to the server's request.  The
   client subsequently sends a service-specific re-authorization request
   containing one or multiple Session-Group-Info AVPs, each indicating a
   session group, group to which the session had been previously assigned.  To
   indicate removal of the indicated session from one or multiple
   session groups, the server sends a service-specific auth authorization response to
   the client, containing a list of Session-Group-Info AVPs with the
   SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id
   AVP identifying the session group, group from which the session should be
   removed.  The server MAY <bcp14>MAY</bcp14> include to with the service-specific auth authorization
   response a list of Session-Group-Info AVPs with the
   SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP
   identifying session groups to which the session remains subscribed.
   If the server decides to remove the identified session from all
   session groups, groups to which the session has been previously assigned,
   the server includes in the service-specific auth authorization response at least
   one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION
   flag cleared and Session-Group-Id AVP absent.</t>
        </section>
        <section title="Mid-session group assignment modifications" anchor="sect-4.2.3"><t> anchor="sect-4.2.3" numbered="true" toc="default">
          <name>Mid-session Group Assignment Modifications</name>
          <t>
   Either Diameter node (client or server) can modify the group
   membership of an active Diameter session according to the specified
   permission considerations.</t>
          <t>
   To update an assigned group mid-session, a Diameter client sends a
   service-specific re-authorization request to the server, containing one or
   multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION
   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
   client MAY <bcp14>MAY</bcp14> send one or multiple Session-Group-Info AVP AVPs with the
   SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP
   identifying the session group from which the identified session is to be
   removed.  To remove the session from all previously assigned session
   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
   present.  When the server received the service-specific re-authorization
   request, it MUST <bcp14>MUST</bcp14> update its locally maintained view of the session groups
   for the identified session according to the appended Session-Group-Info
   AVPs.  The server sends a service- specific auth service-specific authorization response to the client
   containing one or multiple Session-Group-Info AVPs with the
   SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP
   identifying the new session group to which the identified session has been
   assigned.</t>
   <t>
     When a Diameter server decides to update assigned groups mid-session, it
     sends a Re-Authorization Request Re-Auth-Request (RAR) message or a service-specific
     request to the client identifying the session, session for which the session group
     lists are to be updated. The client responds with a Re-Authorization
   Answer Re-Auth-Answer (RAA)
     message or a service-specific answer.  The client subsequently
   sends a service-specific re-authorization request containing one or
   multiple 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 session had been previously assigned.  The server responds with a
   service-specific auth authorization response and includes one or multiple
   Session-Group-Info AVP AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set
   and the Session-Group-Id AVP identifying the session group, group to which the
   identified session is to be assigned.  With the same response message, the
   server MAY <bcp14>MAY</bcp14> send one or multiple Session-Group-Info AVPs with the
   SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP
   identifying the session groups from which the identified session is to be
   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
   the response having the SESSION_GROUP_ALLOCATION_ACTION flag cleared and no
   Session-Group-Id AVP present.</t>
        </section>
      </section>
      <section title="Deleting anchor="sect-4.3" numbered="true" toc="default">
        <name>Deleting a Session Group" anchor="sect-4.3"><t> Group</name>
        <t>
   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-Info AVP having with the SESSION_GROUP_STATUS flag cleared
   and the Session-Group-Id AVP identifying the session group, which group that is
   to be deleted.  The SESSION_GROUP_ALLOCATION_ACTION flag of the
   associated Session-Group-Control-Vector AVP MUST <bcp14>MUST</bcp14> be cleared.</t>
        <t>
   A session group is implicitly deleted and its identifier is released
   after the last session has been removed from this session group.</t>
      </section>
      <section title="Performing anchor="sect-4.4" numbered="true" toc="default">
        <name>Performing Group Operations" anchor="sect-4.4"><section title="Sending Operations</name>
        <section anchor="sect-4.4.1" numbered="true" toc="default">
          <name>Sending Group Commands" anchor="sect-4.4.1"><t> Commands</name>
          <t>
   Either Diameter node (client or server) can request the recipient of a
   request to process an associated command for all sessions assigned to one
   or multiple groups by identifying these groups in the request.  The sender
   of the request appends for each group, group to which the command applies, applies a
   Session-Group-Info AVP including the Session-Group-Id AVP to identify the
   associated session group.  Both,  Both the SESSION_GROUP_ALLOCATION_ACTION flag
   as well as
   and the SESSION_GROUP_STATUS flag MUST <bcp14>MUST</bcp14> be set.</t>
          <t>
   If the Command Code Format (CCF) of the request mandates a Session-Id
   AVP, the Session-Id AVP MUST <bcp14>MUST</bcp14> identify one of the single sessions
   which
   that is assigned to at least one of the groups being identified in
   the appended Session-Group-Id AVPs.</t>
          <t>
   The sender of the request MUST <bcp14>MUST</bcp14> indicate to the receiver how multiple
   resulting transactions associated with a group command are to be treated by
   appending a single instance of a Group-Response-Action AVP.
   For example, when a server sends a Re-Authorization Request Re-Auth-Request (RAR) or a service-specific
   server-initiated request to the client, it indicates to the client to
   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
   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
   RAR message for each identified group individually.  When the server sets
   the Group-Response-Action AVP to PER_SESSION (3), the client follows-up follows up
   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
   one RAR message for that session.</t>
          <t>
   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
   receiving the one or more corresponding answer(s) answers, as the answer(s) answers will only be sent
   back when the request is processed for all the sessions or all the session sessions
   of a session group.  If the processing of the request is delay-sensitive, delay sensitive,
   the sender SHOULD NOT <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
   the request for all the sessions or if the request timeout timer is high
   enough, the sender MAY <bcp14>MAY</bcp14> set the Group-Response-Action AVP to ALL_GROUPS (1)
   or PER_GROUP (2).</t>
          <t>
   If the sender wants the receiver of the request to process the
   associated command solely for a single session, the sender does not
   append any group identifier, but identifier; it identifies only the relevant session in
   the Session-Id AVP.</t>
        </section>
        <section title="Receiving anchor="sect-4.4.2" numbered="true" toc="default">
          <name>Receiving Group Commands" anchor="sect-4.4.2"><t> Commands</name>
          <t>
   A Diameter node receiving a request to process a command for a group
   of sessions, sessions identifies the relevant groups according to the included
   Session-Group-Id AVP in the Session-Group-Info AVP and processes the
   group command according to the included Group-Response-Action AVP.
   If the received request identifies multiple groups in multiple multiple,
   included Session-Group-Id AVPs, the receiver SHOULD <bcp14>SHOULD</bcp14> process the
   associated command for each of these groups.  If a session has been
   assigned to more than one of the identified groups, the receiver MUST <bcp14>MUST</bcp14>
   process the associated command only once per session.</t>
        </section>
        <section title="Error anchor="sect-4.4.3" numbered="true" toc="default">
          <name>Error Handling for Group Commands" anchor="sect-4.4.3"><t> Commands</name>
          <t>
   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
   error that applies to all sessions in the identified groups, an
   associated protocol error MUST <bcp14>MUST</bcp14> be returned to the source of the
   request.  In such case, the sender of the request MUST <bcp14>MUST</bcp14> fall back to
   single-session processing and the session groups, which have been
   identified in the group command, MUST <bcp14>MUST</bcp14> be deleted according to the
   procedure described in <xref target="sect-4.3"/>.</t> target="sect-4.3" format="default"/>.</t>
          <t>
   When a Diameter node receives a request to process a command for one
   or more session groups and the result of processing the command
   succeeds for some sessions identified in one or multiple session
   groups,
   groups but fails for one or more sessions, the Result-Code AVP in
   the response message SHOULD <bcp14>SHOULD</bcp14> indicate DIAMETER_LIMITED_SUCCESS DIAMETER_LIMITED_SUCCESS, as per
   Section 7.1.2 of
   <xref target="RFC6733"/>.</t> target="RFC6733" section="7.1.2" sectionFormat="of" format="default"/>.</t>
          <t>
   In the case of limited success, the sessions, sessions for which the
   processing of the group command failed, MUST failed <bcp14>MUST</bcp14> be identified by
   including their Session-Id AVP in the Failed-AVP AVP AVP, as per
   Section 7.5 of
   <xref target="RFC6733"/>. target="RFC6733" section="7.5" sectionFormat="of" format="default"/>.  The sender of the request MUST <bcp14>MUST</bcp14> fall back
   to single-session operation for each of the identified sessions, sessions for
   which the group command failed.  In addition, each of these sessions
   MUST
   <bcp14>MUST</bcp14> be removed from all session groups to which the group command
   applied.  To remove sessions from a session group, the Diameter
   client performs the procedure described in <xref target="sect-4.2.2"/>.</t> target="sect-4.2.2" format="default"/>.</t>
        </section>
        <section title="Single-Session Fallback" anchor="sect-4.4.4"><t> anchor="sect-4.4.4" numbered="true" toc="default">
          <name>Single-Session Fallback</name>
          <t>
   Either Diameter node can fall back to single session single-session operation by
   ignoring and omitting the optional group session-specific group-session-specific AVPs.
   Fallback to single-session operation is performed by processing the
   Diameter command solely for the session identified in the mandatory
   Session-Id AVP.  In such case, the response to the group command MUST
   NOT identify <bcp14>MUST
   NOT</bcp14>
    include any group identifier but identify solely only the Session-Id identifying the single session for
   which the command has been processed.</t>
        </section>
      </section>
    </section>
    <section title="Operation anchor="sect-5" numbered="true" toc="default">
      <name>Operation with Proxy Agents" anchor="sect-5"><t> Agents</name>
      <t>
   In the case of a present stateful Proxy Agent between a Diameter
   client and a Diameter server, the Proxy Agent MUST <bcp14>MUST</bcp14> perform the same
   mechanisms per this specification to advertise session grouping and
   group operations capability operation capabilities towards the client and the server server,
   respectively.  The Proxy MUST Agent <bcp14>MUST</bcp14> update and maintain consistency of its
   local session states as per the result of the group commands which that
   are operated between a Diameter client and a server.  In such case,
   the Proxy Agent MUST <bcp14>MUST</bcp14> act as a Diameter server in front of the
   Diameter client and MUST <bcp14>MUST</bcp14> act as a Diameter client in front of the
   Diameter server.  Therefore, the client and the server behavior described
   in <xref target="sect-4"/> target="sect-4" format="default"/> applies respectively to the stateful Proxy Agent.</t>
      <t>
   If a stateful Proxy Agent manipulates session groups, it MUST <bcp14>MUST</bcp14>
   maintain consistency of session groups between a client and a server.
   This applies to a deployment where the Proxy Agent utilizes session
   grouping and performs group operations with, for example, a Diameter
   server, whereas the Diameter client is not aware of session groups.
   In such case case, the Proxy Agent must reflect the states associated with
   the session groups as individual session operations towards the
   client and ensure the client has a consistent view of each session.
   The same applies to a deployment where all nodes, the Diameter client
   and server, as well as the Proxy Agent are group-aware group aware, but the Proxy
   Agent manipulates groups, e.g., to adopt different administrative
   policies that apply to the client's domain and the server's domain.</t>
      <t>
   Stateless Proxy Agents do not maintain any session state states (only transaction
   state
   states are maintained).  Consequently, the notion of a session group is
   transparent for any stateless Proxy Agent present between a Diameter client
   and a Diameter server handling session groups.  Session group related  Session-group-related AVPs
   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
   the Proxy Agent for any reason, the Diameter client and Diameter server
   will discover the absence of the related session group session-group-related AVPs and will fall back
   to single-session processing, as described in <xref target="sect-4"/>.</t> target="sect-4" format="default"/>.</t>
    </section>
    <section title="Commands Formatting" anchor="sect-6"><t> anchor="sect-6" numbered="true" toc="default">
      <name>Commands Formatting</name>
      <t>
   This document does not specify new Diameter commands to enable group
   operations,
   operations but relies on command extensibility and capability provided
   by the Diameter Base protocol.  This section provides the guidelines
   to extend the CCF of existing Diameter commands with optional AVPs to
   enable the recipient of the command applying to apply the command to all
   sessions associated with the identified group(s).</t> group or groups.</t>
      <section title="Formatting anchor="sect-6.1" numbered="true" toc="default">
        <name>Formatting Example: Group Re-Auth-Request" anchor="sect-6.1"><t> Re-Auth-Request</name>
        <t>
   A request for re-authentication of one or more groups of users is issued by
   appending one or multiple Session-Group-Id AVP(s), AVPs, as well as appending a single
   instance of a Group-Response-Action AVP to the Re-Auth-Request (RAR).  The
   one
   One or multiple Session-Group-Id AVP(s) AVPs identify the one or more associated group(s) groups
   for which the group re-authentication has been requested.  The
   Group-Response-Action AVP identifies the expected means to perform and
   respond to the group command.  The recipient of the group command initiates
   re-authentication for all users associated with the identified group(s). group or groups.
   Furthermore, the sender of the group re-authentication request appends a
   Group-Response-Action AVP to provide more information to the receiver of
   the command about how to accomplish the group operation.</t>
        <t>
   The value of the mandatory Session-Id AVP MUST <bcp14>MUST</bcp14> identify a session
   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>

	<figure><artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[
      <RAR>  ::= < Diameter Header: 258, REQ, PXY >
                 < Session-Id >
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { Destination-Host }
                 { Auth-Application-Id }
                 { Re-Auth-Request-Type }
                 [ User-Name ]
                 [ Origin-State-Id ]
               * [ Proxy-Info ]
               * [ Route-Record ]
                 [ Session-Group-Capability-Vector ]
               * [ Session-Group-Info ]
                 [ Group-Response-Action ]
               * [ AVP ]
]]></artwork>
	</figure>
      </section>
    </section>
    <section title="Attribute-Value-Pairs (AVP)" anchor="sect-7"><figure><artwork><![CDATA[
                                                  +--------------------+
                                                  |   AVP Flag rules   |
                                                  +----+---+------+----+
                                 AVP              |    |   |SHOULD|MUST|
 Attribute Name                  Code Value Type  |MUST|MAY| NOT  | NOT|
+-------------------------------------------------+----+---+------+----+
|Session-Group-Info              TBD1 Grouped     |    | P |      | V  |
|Session-Group-Control-Vector    TBD2 Unsigned32  |    | P |      | V  |
|Session-Group-Id                TBD3 UTF8String  |    | P |      | V  |
|Group-Response-Action           TBD4 Unsigned32  |    | P |      | V  |
|Session-Group-Capability-Vector TBD5 Unsigned32  |    | P |      | V  |
+-------------------------------------------------+----+---+------+----+

                   AVPs anchor="sect-7" numbered="true" toc="default">
      <name>Attribute-Value Pairs (AVPs)</name>

<table>
<name>AVPs for the Diameter Group Signaling
]]></artwork>
	</figure> Signaling</name>
<thead>
<tr>
<th>Attribute Name</th>
<th rowspan="2" colspan="1">AVP Code Value Type</th>
<th rowspan="1" colspan="4">AVP Flag rules</th>
</tr>
<tr>
<th></th>
<th><bcp14>MUST</bcp14></th>
<th><bcp14>MAY</bcp14></th>
<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>

      <section title="Session-Group-Info AVP" anchor="sect-7.1"><t> anchor="sect-7.1" numbered="true" toc="default">
        <name>Session-Group-Info AVP</name>
        <t>
   The Session-Group-Info AVP (AVP Code TBD1) 671) is of type Grouped.  It
   contains the identifier of the session group group, as well as an indication
   of the node responsible for session group identifier assignment.</t>

	<figure><artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[
   Session-Group-Info ::= < AVP Header: TBD1 671 >
                          < Session-Group-Control-Vector >
                          [ Session-Group-Id ]
                        * [ AVP ]
]]></artwork>
	</figure>
      </section>
      <section title="Session-Group-Control-Vector AVP" anchor="sect-7.2"><t> anchor="sect-7.2" numbered="true" toc="default">
        <name>Session-Group-Control-Vector AVP</name>
        <t>
   The Session-Group-Control-Vector AVP (AVP Code TBD2) 672) is of type
   Unsigned32 and contains a 32-bit flags flag field to control the group
   assignment at session-group aware session-group-aware nodes.  For defined flags flags, only
   numeric values that are 2^x 2<sup>x</sup> (power of two, where 0&lt;=x&lt;32) are allowed.</t>
        <t>
   The following control flags are defined in this document:</t>
        <t>SESSION_GROUP_ALLOCATION_ACTION (0x00000001)

	<list><t>

        </t>
        <ul empty="true" spacing="normal">
          <li>
	This flag indicates the action to be performed for the identified
      session.  When this flag is set, it indicates that the identified
      Diameter session is to be assigned to the session group as
      identified by the Session-Group-Id AVP or the session's assignment
      to the session group identified in the Session-Group-Id AVP is
      still valid.  When the flag is cleared, the identified Diameter
      session is to be removed from at least one session group.  When
      the flag is cleared and the Session-Group-Info AVP identifies a
      particular session group in the associated Session-Group-Id AVP,
      the session is to be removed solely from the identified session
      group.  When the flag is cleared and the Session-Group-Info AVP
      does not identify a particular session group (Session-Group-Id AVP
      is absent), the identified Diameter session is to be removed from
      all session groups to which it has been previously assigned.
	</t>
	</list></t>
	</li>
        </ul>
        <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
      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
      cleared, the identified session group is deleted and the associated
      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 <bcp14>MUST</bcp14> be
      ignored by the receiver.
	</t>
	</list></t>
	</li>
        </ul>
      </section>
      <section title="Session-Group-Id AVP" anchor="sect-7.3"><t> anchor="sect-7.3" numbered="true" toc="default">
        <name>Session-Group-Id AVP</name>
        <t>
   The Session-Group-Id AVP (AVP Code TBD3) 673) is of type UTF8String and
   identifies a group of Diameter sessions.</t>
        <t>
   The Session-Group-Id MUST <bcp14>MUST</bcp14> be globally unique.  The Session-Group-Id
   includes a mandatory portion and an implementation-defined portion
   delimited by the ";" character.  The Session-Group-Id MUST <bcp14>MUST</bcp14> begin with
   the identity of the Diameter node that owns the session group.  The
   remainder of the Session-Group-Id is implementation-defined implementation defined and MAY <bcp14>MAY</bcp14>
   follow the format recommended for the implementation-defined portion
   of the Session-Id AVP in section 8.8 of <xref target="RFC6733"/>.</t> target="RFC6733" section="8.8" sectionFormat="of" format="default"/>.</t>
      </section>
      <section title="Group-Response-Action AVP" anchor="sect-7.4"><t> anchor="sect-7.4" numbered="true" toc="default">
        <name>Group-Response-Action AVP</name>
        <t>
   The Group-Response-Action AVP (AVP Code TBD4) 674) is of type Unsigned32
   and contains a 32-bit address space representing values indicating
   how the node SHOULD <bcp14>SHOULD</bcp14> issue follow up follow-up exchanges in response to a
   command which that impacts multiple sessions.  The following values are
	defined by this document:</t>

	<t>ALL_GROUPS (1)

	<list>
	<t>Follow up

	<dl newline="true">
        <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
      groups.</t>
        </list></t>

	<t>PER_GROUP (2)
	<list>
	<t>Follow up
      groups.</dd>

        <dt>PER_GROUP (2)</dt>
          <dd>Follow-up message exchanges associated with a group command should
      be performed with a separate message exchange for each impacted
      group.</t>
        </list></t>

	<t>PER_SESSION (3)
	<list>
	<t>Follow up
      group.</dd>
        <dt>PER_SESSION (3)</dt>
          <dd>Follow-up message exchanges associated with a group command should
      be performed with a separate message exchange for each impacted
      session.</t>
	</list>	</t>
      session.</dd>
        </dl>

      </section>
      <section title="Session-Group-Capability-Vector AVP" anchor="sect-7.5"><t> anchor="sect-7.5" numbered="true" toc="default">
        <name>Session-Group-Capability-Vector AVP</name>
        <t>
   The Session-Group-Capability-Vector AVP (AVP Code TBD5) 675) is of type
   Unsigned32 and contains a 32-bit flags flag field to indicate capabilities
   in the context of session-group assignment and group operations.  For
   defined flags flags, only numeric values that are 2^x 2<sup>x</sup> (power of two, where
   0&lt;=x&lt;32) are allowed.  The value of (0) is reserved.</t>
        <t>
   The following capabilities are capability is defined in this document:</t>
        <t>BASE_SESSION_GROUP_CAPABILITY (0x00000001)
	<list>
	<t>This
        </t>
        <ul empty="true" spacing="normal">
          <li>This flag indicates the capability to support session grouping and
      session group operations according to this specification.	</t>
	</list>
	</t>	</li>
        </ul>
      </section>
    </section>
    <section title="Result-Code anchor="sect-8" numbered="true" toc="default">
      <name>Result-Code AVP Values" anchor="sect-8"><t> Values</name>
      <t>
   This document does not define new Result-Code <xref target="RFC6733"/> target="RFC6733" format="default"/> values for
   existing applications, which are extended to support group commands.
   Specification documents of
   Documents specifying new applications, which will have
   intrinsic support for group commands, may specify new Result-Codes.</t>
    </section>
    <section title="IANA Considerations" anchor="sect-9"><t> anchor="sect-9" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   This section contains the namespaces that have either been created in
   this specification or had their values assigned to existing
   namespaces managed by IANA.</t>
      <section title="AVP Codes" anchor="sect-9.1"><t>
   This specification requires anchor="sect-9.1" numbered="true" toc="default">
        <name>AVP Codes</name>
        <t>
   IANA to register has registered the following new AVPs
   from the AVP Code namespace "AVP Codes" registry defined in <xref target="RFC6733"/>.</t>

	<t><list style="symbols"><t>Session-Group-Info</t>

	<t>Session-Group-Control-Vector</t>

	<t>Session-Group-Id</t>

	<t>Group-Response-Action</t>

	<t>Session-Group-Capability-Vector</t>

	</list>
	</t>

	<t> target="RFC6733" format="default"/>.    The AVPs are defined in <xref target="sect-7"/>.</t> target="sect-7" format="default"/>.</t>

<ul>
<li>Session-Group-Info</li>
<li>Session-Group-Control-Vector</li>
<li>Session-Group-Id</li>
<li>Group-Response-Action</li>
<li>Session-Group-Capability-Vector</li>
</ul>

      </section>
      <section title="New Registries" anchor="sect-9.2"><t>
   This specification requires anchor="sect-9.2" numbered="true" toc="default">
        <name>New Registries</name>
        <t>
   IANA to create has created the following two registries:</t>

	<t><list style="symbols"><t>Session-Group-Control-Vector AVP new registries.</t>
        <ul spacing="normal">
          <li>The "Session-Group-Control-Vector AVP Values (code 672)" registry for control bits with
      two bits. Two initial assignments, which assignments are described in <xref target="sect-7.2"/>. target="sect-7.2" format="default"/>.  The
      future registration assignment policy is proposed to be
      Specification Required.</t>

	<t>Session-Group-Capability-Vector AVP with one Required.</li>
          <li>The "Session-Group-Capability-Vector AVP Values (code 675)" registry. One initial assignment,
      which assignment is described in <xref target="sect-7.5"/>. target="sect-7.5" format="default"/>.  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> Action.</li>
        </ul>
      </section>
    </section>
    <section title="Security Considerations" anchor="sect-10"><t> anchor="sect-10" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   The security considerations of the Diameter protocol itself are discussed
   in <xref target="RFC6733"/>. target="RFC6733" format="default"/>.  Use of the AVPs defined in this document MUST <bcp14>MUST</bcp14> take into
   consideration the security issues and requirements of the Diameter base
   protocol.  In particular, the Session-Group-Info AVP (including the
   Session-Group-Control-Vector and the Session-Group-Id AVPs) should be
   considered as a security-sensitive AVPs AVP in the same manner than as the
   Session-Id AVP in the Diameter base protocol <xref target="RFC6733"/>.</t> target="RFC6733" format="default"/>.</t>
      <t>
   The management of session groups relies upon the existing trust
   relationship between the Diameter client and the Diameter server
   managing the groups of sessions.  This document defines a mechanism
   that allows a client or a server to act on multiple sessions at the
   same time using only one command.  If the Diameter client or server
   is compromised, an attacker could launch DoS attacks by terminating
   or applying change operations to a large number of sessions with a
   limited set of commands using the session group management concept.</t>
      <t>
   According to the Diameter base protocol <xref target="RFC6733"/>, target="RFC6733" format="default"/>, transport
   connections between Diameter peers are protected by TLS/TCP, DTLS/
   SCTP DTLS /
   Stream Control Transmission Protocol (SCTP), or alternative security mechanisms that are independent of
   Diameter, such as IPsec.  However, the lack of end-to-end security
   features makes it difficult to establish trust in the session group
   related session-group-related
   information received from non-adjacent nodes.  Any Diameter
   agent in the message path can potentially modify the content of the
   message and therefore the information sent by the Diameter client or
   the server.  There is ongoing work on the specification of end-to-end
   security features for Diameter.  Such features would enable the
   establishment of a trust relationship between non-adjacent nodes nodes, and
   the security required for session group management would normally
   rely on this end-to-end security.  However, there is no assumption in
   this document that such end-to-end security mechanism will be
   available.  It is only assumed that the solution defined on this
   document relies on the security framework provided by the Diameter
   based Diameter-based protocol.</t>
      <t>
   In some cases, a Diameter Proxy agent Agent can act on behalf of a client
   or a server.  In such a case, the security requirements that normally
   apply to a client (or a server) apply equally to the Proxy agent.</t>

	</section>

	<section title="Acknowledgments" anchor="sect-11"><t>
   The authors of this document want to thank Ben Campbell and Eric
   McMurry for their valuable comments to early versions of this draft.
   Furthermore, authors thank Steve Donovan and Mark Bales for the
   thorough review and comments on advanced versions of the WG document,
   which helped a lot to improve this specification.</t> Agent.</t>
    </section>
  </middle>
  <back>
	<references title="Normative References">
	&RFC2119;
	&RFC8174;
	&RFC6733;
	&RFC7155;
    <references>
      <name>Normative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6733.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7155.xml"/>
    </references>
    <section title="Session anchor="sect-a" numbered="true" toc="default">
      <name>Session Management -- Exemplary Session State Machine" anchor="sect-a"><section title="Use Machine</name>
      <section anchor="sect-a.1" numbered="true" toc="default">
        <name>Use of groups Groups for the Authorization Session State Machine" anchor="sect-a.1"><t>
   Section 8.1 in Machine</name>
        <t>
   <xref target="RFC6733"/> target="RFC6733" sectionFormat="of" section="8.1" format="default"/> defines a set of finite state machines,
   representing machines that
   represent the life cycle of Diameter sessions, and which must be
   observed by all Diameter implementations that make use of the
   authentication and/or authorization portion of a Diameter
   application.  This section defines, as for example, additional state
   transitions related to the processing of the group commands which that may
   impact multiple sessions.</t>
        <t>
   The group membership is a session state state, and therefore only those state
   machines from <xref target="RFC6733"/> target="RFC6733" format="default"/> in which the server is maintaining session
   state are relevant in this document.
   As in <xref target="RFC6733"/>, target="RFC6733" format="default"/>, the term
   Service-Specific
   'service-specific' below refers to a message defined in a Diameter
   application (e.g., Mobile IPv4, IPv4 or NASREQ).</t>
        <t>
   The following state machine is observed by a client when the state is
   maintained on the server.  State transitions which that are unmodified
   from <xref target="RFC6733"/> target="RFC6733" format="default"/> are not repeated here.</t>
        <t>
   The Diameter group command in the following tables is differentiated
   from a single-session related single-session-related command by a preceding 'G' (Group).  A
   Group Re-Auth Request, which applies to one or multiple session
   groups, has been exemplarily described in <xref target="sect-6.1"/>. target="sect-6.1" format="default"/>.  Such Group
   RAR command is denoted as 'GRAR' in the following table.  The same
	notation applies to other commands commands, as per <xref target="RFC6733"/>.</t>

	<figure><artwork><![CDATA[
                           CLIENT, STATEFUL
   State     Event                          Action       New target="RFC6733" format="default"/>.</t>
	<t>Additionally, the following acronyms are used in the tables below.</t>
	<dl newline="false" spacing="normal">
	  <dt>GASR:</dt>
	  <dd>Group-Abort-Session-Request</dd>
	  <dt>GASA:</dt>
	  <dd>Group-Abort-Session-Answer</dd>
	  <dt>GSTA:</dt>
	  <dd>Group-Session-Termination-Answer</dd>
	  <dt>GSTR:</dt>
	  <dd>Group-Session-Termination-Request </dd>
	</dl>
<table>
<name>Group Authorization Session State
   ---------------------------------------------------------------
   Idle      Client Machine for Stateful Client</name>
<thead>
<tr>
<th colspan="4">CLIENT, STATEFUL</th>
</tr>
<tr>

<th>State</th>
<th>Event</th>
<th>Action</th>
<th>New State</th>
</tr>
</thead>
<tbody>
<tr>

<td>Idle</td>
<td>Client or Device Requests access</td>
<td> Send         Pending
             access                         service
                                            specific
                                            auth
service-specific
authorization req
optionally
including
                                            groups

   Open      GASR
groups</td>
<td>Pending</td>
</tr>
<tr>

<td>Open</td>
<td>GASR received with             Send GASA    Discon
Group-Response-Action          with
= ALL_GROUPS,                  Result-Code
session is assigned to         = SUCCESS,
received group(s) and          Send GSTR.
client will comply with
request to end the session

   Open      GASR session</td>
<td>Send GASA
Result-Code
= SUCCESS,
Send GSTR</td>
<td>Discon</td>
</tr>

<tr>
<td>Open</td>
<td>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 session</td>
<td>Send GASA
with
Result-Code
= SUCCESS,
Send GSTR
per group</td>
<td>Discon</td>
</tr>

<tr>
<td>Open</td>
<td> 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 session</td>
<td>Send GASA    Open
with
Result-Code
= SUCCESS,
Send STR
per session</td>
<td>Discon</td>
</tr>

<tr>
<td>Open</td>
 <td>GASR received,
 client will not comply with    with
 request to end all session     Result-Code sessions
 in received group(s) group(s)</td>
<td>Send GASA
with
Result-Code
!= SUCCESS

   Discon    GSTA Received                  Discon.      Idle
                                            user/device

   Open      GRAR SUCCESS</td>
<td>Open</td>
</tr>

<tr>
<td>Discon</td>
<td>GSTA received</td>
<td>Discon.
user/device</td>
<td>Idle</td>
</tr>

<tr>
<td>Open</td>

<td>GRAR received with             Send GRAA,   Pending
Group-Response-Action          Send
= ALL_GROUPS,                  service
session is assigned to         specific
received group(s) and          group
client will perform            re-auth req
subsequent re-auth</td>
<td>Send GRAA,
Send
service-specific
group
re-auth

   Open      GRAR req</td>
<td>Pending</td>
</tr>

<tr>
<td>Open</td>
<td>GRAR received with             Send GRAA,   Pending
Group-Response-Action          Send
= PER_GROUP,                   service
session is assigned to         specific
received group(s) and          group
client will perform            re-auth req
subsequent re-auth             per </td>
<td>Send GRAA,
Send
service-specific
group

   Open      GRAR
re-auth req
per group</td>
<td>Pending</td>
</tr>

<tr>
<td>Open</td>
<td>GRAR received with             Send GRAA,   Pending
Group-Response-Action          Send
= PER_SESSION,                 service
session is assigned to         specific
received group(s) and          re-auth req
client will perform            per session
subsequent re-auth</td>
<td>Send GRAA,
Send
service-specific
re-auth

   Open      GRAR req
per session</td>
<td>Pending</td>
</tr>

<tr>
<td>Open</td>
<td>GRAR received and client will  Send GRAA    Idle
not perform subsequent
re-auth</td>
<td>Send GRAA
with
             re-auth
Result-Code
!= SUCCESS,
Discon.
                                            user/device

   Pending   Successful
user/device</td>
<td>Idle</td>
</tr>

<tr>
<td>Pending</td>
<td>Successful service-specific    Provide      Open
group re-authorization answer  service
             received.

   Pending   Failed
received</td>
<td>Provide
service</td>
<td>Open</td>
</tr>

<tr>
<td>Pending</td>
<td>Failed service-specific        Discon.      Idle
group re-authorization answer  user/device
             received.
]]></artwork>
	</figure>
received</td>
<td>Discon.
user/device</td>
<td>Idle</td>
</tr>
</tbody>
</table>

        <t>
   The following state machine is observed by a server when it is
   maintaining the state for the session.  State transitions which that are
   unmodified from <xref target="RFC6733"/> target="RFC6733" format="default"/> are not repeated here.</t>

	<figure><artwork><![CDATA[
                             SERVER, STATEFUL
   State     Event                          Action       New

<table>
<name>Group Authorization Session State
   ---------------------------------------------------------------

   Idle      Service-specific Machine for Stateful Server</name>
<thead>
<tr>
<th colspan="4">SERVER, STATEFUL</th>
</tr>
<tr>

<th>State</th>
<th>Event</th>
<th>Action</th>
<th>New State</th>
</tr>
</thead>

<tbody>
<tr>
<td>Idle</td>
<td>Service-specific authorization Send         Open
request received, and user     successful
is authorized                  service
                                            specific authorized</td>
<td>Send
successful
service-specific
answer
optionally
including
                                            groups

   Open      Server
groups</td>
<td>Open</td>
</tr>

<tr>
<td>Open</td>
<td>Server wants to terminate      Send GASR    Discon
             group(s)

   Discon    GASA received                  Cleanup      Idle

   Any       GSTR received                  Send
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>

<tr>
<td>Any</td>
<td>GSTR received</td>
<td>Send GSTA,   Idle
                                            Cleanup

   Open      Server Cleanup</td>
<td>Idle</td>
</tr>

<tr>
<td>Open</td>
<td>Server wants to reauth         Send GRAR    Pending
             group(s)

   Pending   GRAA
group(s)</td>
<td>Send GRAR</td>
<td>Pending</td>
</tr>
<tr>
<td>Pending</td>
<td>GRAA received with Result-Code Update       Open
= SUCCESS                      session(s)

   Pending   GRAA SUCCESS</td>
<td>Update session(s)</td>
<td>Open</td>
</tr>
<tr>
<td>Pending</td>
<td>GRAA received with Result-Code Cleanup      Idle
!= SUCCESS                     session(s)

   Open      Service-specific SUCCESS</td>
<td>Cleanup session(s)</td>
<td>Idle</td>
</tr>
<tr>
<td>Open</td>
<td>Service-specific group         Send         Open
             re-authoization
re-authorization request        successful
received and user is           service
             authorized                     specific
authorized</td>
<td>Send
successful
service-specific
group
re-auth
                                            answer

   Open      Service-specific
answer</td>
<td>Open</td>
</tr>
<tr>
<td>Open</td>
<td>Service-specific group         Send         Idle
re-authorization request       failed
received and user is           service
not authorized                 specific authorized</td>
<td>Send
failed
service-specific
group
re-auth
answer,
                                            cleanup
]]></artwork>
	</figure>
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 document.
   Furthermore, the authors thank <contact fullname="Steve Donovan"/> and <contact 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>