draft-ietf-dime-group-signaling-12.txt   draft-ietf-dime-group-signaling-13.txt 
Diameter Maintenance and Extensions (DIME) M. Jones Diameter Maintenance and Extensions (DIME) M. Jones
Internet-Draft Internet-Draft
Intended status: Standards Track M. Liebsch Intended status: Standards Track M. Liebsch
Expires: July 1, 2019 Expires: September 10, 2020
L. Morand L. Morand
December 28, 2018 March 9, 2020
Diameter Group Signaling Diameter Group Signaling
draft-ietf-dime-group-signaling-12.txt draft-ietf-dime-group-signaling-13.txt
Abstract Abstract
In large network deployments, a single Diameter node can support over In large network deployments, a single Diameter node can support over
a million concurrent Diameter sessions. Recent use cases have a million concurrent Diameter sessions. Recent use cases have
revealed the need for Diameter nodes to apply the same operation to a revealed the need for Diameter nodes to apply the same operation to a
large group of Diameter sessions concurrently. The Diameter base large group of Diameter sessions concurrently. The Diameter base
protocol commands operate on a single session so these use cases protocol commands operate on a single session so these use cases
could result in many thousands of command exchanges to enforce the could result in many thousands of command exchanges to enforce the
same operation on each session in the group. In order to reduce same operation on each session in the group. In order to reduce
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 1, 2019. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Building and Modifying Session Groups . . . . . . . . . . 4 3.1. Building and Modifying Session Groups . . . . . . . . . . 4
3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . 4 3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . 4
3.3. Permission Considerations . . . . . . . . . . . . . . . . 4 3.3. Permission Considerations . . . . . . . . . . . . . . . . 5
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
4.1. Session Grouping Capability Discovery . . . . . . . . . . 7 4.1. Session Grouping Capability Discovery . . . . . . . . . . 6
4.1.1. Explicit Capability Discovery . . . . . . . . . . . . 7 4.1.1. Implicit Capability Discovery . . . . . . . . . . . . 6
4.1.2. Implicit Capability Discovery . . . . . . . . . . . . 7 4.1.2. Explicit Capability Discovery . . . . . . . . . . . . 7
4.2. Session Grouping . . . . . . . . . . . . . . . . . . . . 7 4.2. Session Grouping . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Group assignment at session initiation . . . . . . . 8 4.2.1. Group assignment at session initiation . . . . . . . 8
4.2.2. Removing a session from a session group . . . . . . . 11 4.2.2. Removing a session from a session group . . . . . . . 10
4.2.3. Mid-session group assignment modifications . . . . . 12 4.2.3. Mid-session group assignment modifications . . . . . 12
4.3. Deleting a Session Group . . . . . . . . . . . . . . . . 13 4.3. Deleting a Session Group . . . . . . . . . . . . . . . . 13
4.4. Performing Group Operations . . . . . . . . . . . . . . . 13 4.4. Performing Group Operations . . . . . . . . . . . . . . . 13
4.4.1. Sending Group Commands . . . . . . . . . . . . . . . 13 4.4.1. Sending Group Commands . . . . . . . . . . . . . . . 13
4.4.2. Receiving Group Commands . . . . . . . . . . . . . . 14 4.4.2. Receiving Group Commands . . . . . . . . . . . . . . 14
4.4.3. Error Handling for Group Commands . . . . . . . . . . 14 4.4.3. Error Handling for Group Commands . . . . . . . . . . 14
4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 15 4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 15
5. Operation with Proxy Agents . . . . . . . . . . . . . . . . . 15 5. Operation with Proxy Agents . . . . . . . . . . . . . . . . . 15
6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 16 6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 16
6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 16 6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 16
skipping to change at page 3, line 50 skipping to change at page 3, line 50
o Fallback to single session operation o Fallback to single session operation
o Implicit discovery of capability to support grouping and group o Implicit discovery of capability to support grouping and group
operations 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 Diameter peer's capability to support session grouping and session
group operations group operations
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses terminology defined in [RFC6733]. This document uses terminology defined in [RFC6733].
3. Protocol Overview 3. Protocol Overview
3.1. Building and Modifying Session Groups 3.1. Building and Modifying Session Groups
Client and Server can assign a new Diameter session to a group, e.g. Client and Server can assign a new Diameter session to a group, e.g.,
in case the subscription profile of the associated user has similar in case the subscription profile of the associated user has similar
characteristics as the profile of other users whose Diameter session characteristics as the profile of other users whose Diameter session
has been assigned to one or multiple groups. A single command can be has been assigned to one or multiple groups. A single command can be
issued and applied to all sessions associated with such group(s), issued and applied to all sessions associated with such group(s),
e.g. to adjust common profile or policy settings. e.g., to adjust common profile or policy settings.
The assignment of a Diameter session to a group can be changed mid- The assignment of a Diameter session to a group can be changed during
session. For example, if a user's subscription profile changes mid- an ongoing session (mid-session). For example, if a user's
session, a Diameter server may remove the session from its current subscription profile changes mid-session, a Diameter server may
group and assign the session to a different group that is more remove a session from an existing group and assign this session to a
appropriate for the new subscription profile. different group that is more appropriate for the new subscription
profile.
In case of mobile users, the user's session may get transferred to a In the case of mobile users, the user's session may get transferred
new Diameter client during handover and assigned to a different mid-session to a new Diameter client during handover and assigned to
group, which is maintained at the new Diameter client, mid-session. a different group, which is maintained at the new Diameter client.
A session group, which has sessions assigned, can be deleted, e.g. A session group, which has sessions assigned, can be deleted, e.g.,
due to a change in multiple users' subscription profile so that the due to a change in multiple users' subscription profile so that the
group's assigned sessions do not share certain characteristics group's assigned sessions do not share certain characteristics
anymore. Deletion of such group requires subsequent individual anymore. Deletion of such group requires subsequent individual
treatment of each of the assigned sessions. A node may decide to treatment of each of the assigned sessions. A node may decide to
assign some of these sessions to any other existing or new group. assign some of these sessions to any other existing or new group.
3.2. Issuing Group Commands 3.2. Issuing Group Commands
Changes in the network condition may result in the Diameter server's Changes in the network condition may result in the Diameter server's
decision to close all sessions in a given group. The server issues a decision to close all sessions in a given group. As example, the
single Session Termination Request (STR) command , identifying the server issues a single Session Termination Request (STR) command,
group of sessions which are to be terminated. The Diameter client including the identifier of the group of sessions which are to be
treats the STR as group command and initiates termination of all terminated. The Diameter client treats the STR as group command and
sessions associated with the identified group. Subsequently, the initiates the termination of all sessions associated with the
client confirms successful termination of these sessions to the identified group. Subsequently, the client confirms the successful
server by sending a single Session Termination Answer (STA) command, termination of these sessions to the server by sending a single
which includes the identifier of the group. Session Termination Answer (STA) command, which includes the
identifier of the group.
3.3. Permission Considerations 3.3. Permission Considerations
Permission considerations in the context of this draft apply to the Permission considerations in the context of this draft 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 a session to/from a session group and to delete an existing remove a session to/from a session group and to delete an existing
session group. session group.
This specification follows the most flexible model where both, a This specification follows the most flexible model where both, a
Diameter client and a Diameter server can create a new group and Diameter client and a Diameter server can create a new group and
assign a new identifier to that session group. When a Diameter node assign a new identifier to that session group. When a client or a
decides to create a new session group, e.g. to group all sessions server decides to create a new session group, e.g., to group all
which share certain characteristics, the node builds a session group sessions which share certain characteristics, this node builds a
identifier according to the rules described in Section 7.3 and session group identifier according to the rules described in
becomes the owner of the group. This specification does not Section 7.3 and becomes the owner of the group. This specification
constrain the permission to add or remove a session to/from a session does not restrict the permission to add or remove a session to/from a
group to the group owner, instead each node can add a session to any session group to the group owner. Either the client and the server
known group or remove a session from a group. A session group is can assign a session to a group. However, a session can be removed
deleted and its identifier released after the last session has been from a session group and/or moved to another session group only by
removed from the session group. Also the modification of groups in the node that has assigned this session to the session group. A
terms of moving a session from one session group to a different session group is deleted and its identifier released after the last
session group is permitted to any Diameter node. A Diameter node can session has been removed from this session group. The owner of a
delete a session group and its group identifier mid-session, session group can delete a session group and its group identifier
resulting in individual treatment of the sessions which have been mid-session, resulting in individual treatment of the sessions which
previously assigned to the deleted group. Prerequisite for deletion have been previously assigned to the deleted group. A session group
of a session group is that the Diameter node created the session must only be deleted by the Diameter node that created it.
beforehand, hence the node became the group owner.
The enforcement of more constrained permissions is left to the Diameter applications with implicit support for session groups MAY
specification of a particular group signaling enabled Diameter define a more constrained permission model. For example, a more
application and compliant implementations of such application MUST constrained model could require that a client must not remove a
enforce the associated permission model. Details about enforcing a session from a group which is owned by the server. Details about
more constraint permission model are out of scope of this enforcing a more constraint permission model are out of scope of this
specification. For example, a more constrained model could require specification.
that a client MUST NOT remove a session from a group which is owned
by the server.
The following table depicts the permission considerations as per the The following table depicts the permission considerations as per the
present specification: present specification:
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Operation | Server | Client | | Operation | Server | Client |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Create a new Session Group (Diameter node | X | X | | Create a new Session Group (Diameter node | X | X |
| becomes the group owner) | | | | becomes the group owner) | | |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
skipping to change at page 6, line 22 skipping to change at page 6, line 22
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Assign a Session to a non-owned Session Group | X | X | | Assign a Session to a non-owned Session Group | X | X |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Remove a Session from an owned Session Group | X | X | | Remove a Session from an owned Session Group | X | X |
+-------------------------------------------------+-----------------+ +-------------------------------------------------+-----------------+
| Remove a Session from a non-owned Session Group | X | X | | Remove a Session from a non-owned Session Group | X | X |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Remove a Session from a Session Group where the | X | X | | Remove a Session from a Session Group where the | X | X |
| Diameter node created the assignment | | | | Diameter node created the assignment | | |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Remove a Session from a Session Group where a | | | | Remove a Session from a Session Group where the | | |
| different Diameter node created the assignment | | | | Diameter node did not create the assignment | | |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Overrule a different Diameter node's | | | | Overrule a different Diameter node's | | |
| group assignment *) | | | | group assignment *) | | |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Delete a Session Group which is owned by the | X | X | | Delete a Session Group which is owned by the | X | X |
| Diameter node | | | | Diameter node | | |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Delete a Session Group which is not owned by | | | | Delete a Session Group which is not owned by | | |
| the Diameter node | | | | the Diameter node | | |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
Default Permission as per this Specification Default Permission as per this Specification
*) Editors' note: The protocol specification in this document does
not consider overruling a node's assignment of a session to a session
group. Here, overruling is to be understood as a node changing the
group(s) assignment as per the node's request. Group signaling
enabled applications may take such protocol support and associated
protocol semantics into account in their specification. One
exception is adopted in this specification, which allows a Diameter
server to reject a group assignment as per the client's request.
4. Protocol Description 4. Protocol Description
4.1. Session Grouping Capability Discovery 4.1. Session Grouping Capability Discovery
Diameter nodes SHOULD assign a session to a session group and perform Diameter nodes SHOULD NOT perform group operations with peer nodes
session group operations with a node only after having ensured that unless the node has advertised support for session grouping and group
the node announced associated support beforehand. operations.
4.1.1. Explicit Capability Discovery 4.1.1. Implicit Capability Discovery
New Diameter applications may consider support for Diameter session Newly defined Diameter applications may natively support Diameter
grouping and for performing group commands during the standardization session grouping and group operations. Such applications provide
process. Such applications provide intrinsic discovery for the intrinsic discovery for the support of session grouping capability
support of group commands and announce this capability through the using the assigned Application Id advertised during the capability
assigned application ID. exchange phase two Diameter peers establish a transport connection
(see Section 5.3 of [RFC6733]).
System- and deployment-specific means, as well as out-of-band System- and deployment-specific means, as well as out-of-band
mechanisms for capability exchange can be used to announce nodes' mechanisms for capability discovery can be used to announce nodes'
support for session grouping and session group operations. In such support for session grouping and session group operations. In such
case, the optional Session-Group-Capability-Vector AVP, as described case, the optional Session-Group-Capability-Vector AVP, as described
in Section 4.1.2 can be omitted in Diameter messages being exchanged in Section 4.1.2 can be omitted in Diameter messages being exchanged
between nodes. between nodes.
4.1.2. Implicit Capability Discovery 4.1.2. Explicit Capability Discovery
If no explicit mechanism for capability discovery is deployed to If no other mechanism for capability discovery is deployed to enable
enable Diameter nodes to learn about nodes' capability to support Diameter nodes to learn about nodes' capability to support session
session grouping and group commands, a Diameter node SHOULD append grouping and group commands for a given application, a Diameter node
the Session-Group-Capability-Vector AVP to any Diameter messages SHOULD append the Session-Group-Capability-Vector AVP to any Diameter
exchanged with its nodes to announce its capability to support application messages exchanged with the other Diameter nodes to
session grouping and session group operations. Implementations announce its capability to support session grouping and session group
following the specification as per this document set the operations for the advertised application. Implementations following
the specification as per this document MUST set the
BASE_SESSION_GROUP_CAPABILITY flag of the Session-Group-Capability- BASE_SESSION_GROUP_CAPABILITY flag of the Session-Group-Capability-
Vector AVP. Vector AVP.
When a Diameter node receives at least one Session-Group-Capability- When a Diameter node receives at least one Session-Group-Capability-
Vector AVP from a node with the BASE_SESSION_GROUP_CAPABILITY flag Vector AVP from a node with the BASE_SESSION_GROUP_CAPABILITY flag
set, the Diameter node maintains a log to remember the node's set, the receiving Diameter node discovers the supported session
capability to support group commands. grouping capability of the sending Diameter node for the advertised
application and MUST cache this information for the lifetime of the
routing table entry associated with the peer identity/Application Id
pair (see Section 2.7 of [RFC6733]).
4.2. Session Grouping 4.2. Session Grouping
This specification does not limit the number of session groups, to This specification does not limit the number of session groups to
which a single session is assigned. It is left to the application to which a single session is assigned. It is left to the implementation
determine the policy of session grouping. In case an application of an application to determine such limitations. If an application
facilitates a session to belong to multiple session groups, the facilitates a session to belong to multiple session groups, the
application MUST maintain consistency of associated application application MUST maintain consistency of associated application
session states for these multiple session groups. session states for these multiple session groups.
Either Diameter node (client or server) can initiate the assignment Either Diameter node (client or server) can initiate the assignment
of a session to a single or multiple session groups. Modification of of a session to a single or multiple session groups. Modification of
a group by removing or adding a single or multiple user sessions can a group by removing or adding a single or multiple user sessions can
be initiated and performed mid-session by either Diameter node. be initiated and performed mid-session by either Diameter node
Diameter AAA applications typically assign client and server roles to responsible for the session assignment to this group. Diameter AAA
the Diameter nodes, which are referred to as relevant Diameter nodes applications typically assign client and server roles to the Diameter
to utilize session grouping and issue group commands. Section 5 nodes, which are referred to as relevant Diameter nodes to utilize
describes particularities about session grouping and performing group session grouping and issue group commands. Section 5 describes
commands when relay agents or proxies are deployed. particularities about session grouping and performing group commands
when relay agents or proxies are deployed.
Diameter nodes, which are group-aware, MUST store and maintain an Diameter nodes, which are group-aware, MUST store and maintain an
entry about the group assignment together with a session's state. A entry about the group assignment together with a session's state. A
list of all known session groups should be locally maintained on each list of all known session groups is locally maintained on each node,
node, each group pointing to individual sessions being assigned to each group pointing to individual sessions being assigned to the
the group. A Diameter node MUST also keep a record about sessions, group. A Diameter node MUST also keep a record about sessions, which
which have been assigned to a session group by itself. have been assigned to a session group by itself.
4.2.1. Group assignment at session initiation 4.2.1. Group assignment at session initiation
To assign a session to a group at session initiation, a Diameter To assign a session to a group at session initiation, a Diameter
client sends a service specific request, e.g. NASREQ AA-Request client sends a service specific request, e.g., NASREQ AA-Request
[RFC7155], containing one or more session group identifiers. Each of [RFC7155], containing one or more session group identifiers. Each of
these groups MUST be identified by a unique Session-Group-Id these groups MUST be identified by a unique Session-Group-Id
contained in a separate Session-Group-Info AVP as specified in contained in a separate Session-Group-Info AVP as specified in
Section 7. Section 7.
The client may choose one or multiple session groups from a list of The client may choose one or multiple session groups from a list of
existing session groups. Alternatively, the client may decide to existing session groups. Alternatively, the client may decide to
create a new group to which the session is assigned and identify create a new group to which the session is assigned and identify
itself in the <DiameterIdentity> portion of the Session-Group-Id AVP itself in the <DiameterIdentity> portion of the Session-Group-Id AVP
as per Section 7.3. For all assignments of a session to an active as per Section 7.3. For all assignments of a session to an active
skipping to change at page 9, line 6 skipping to change at page 8, line 47
assigned to the identified session group. assigned to the identified session group.
The client may also indicate in the request that the server is The client may also indicate in the request that the server is
responsible for the assignment of the session in one or multiple responsible for the assignment of the session in one or multiple
sessions owned by the server. In such a case, the client MUST sessions owned by the server. In such a case, the client MUST
include the Session-Group-Info AVP in the request including the include the Session-Group-Info AVP in the request including the
Session-Group-Control-Vector AVP with the Session-Group-Control-Vector AVP with the
SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP. SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP.
If the Diameter server receives a command request from a Diameter If the Diameter server receives a command request from a Diameter
client and the command comprises at least one Session-Group-Info AVP client and the command includes at least one Session-Group-Info AVP
having the SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group- having the SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group-
Control-Vector AVP set, the server can accept or reject the request Control-Vector AVP set, the server can accept or reject the request
for group assignment. Reasons for rejection may be e.g. lack of for group assignment. Reasons for rejection may be e.g., lack of
resources for managing additional groups. When rejected, the session resources for managing additional groups. When rejected, the session
MUST NOT be assigned to any session group. MUST NOT be assigned to any session group.
If the Diameter server accepts the client's request for a group If the Diameter server accepts the client's request for a group
assignment, the server MUST assign the new session to each of the one assignment, the server MUST assign the new session to each of the one
or multiple identified session groups when present in the Session- or multiple identified session groups when present in the Session-
Group-Info AVP. In case one or multiple identified session groups Group-Info AVP. If one or multiple identified session groups are not
are not already stored by the server, the server MUST store the new already stored by the server, the server MUST store the newly
identified group(s) to its local list of known session groups. When identified group(s) to its local list of known session groups. When
sending the response to the client, e.g. a service-specific auth sending the response to the client, e.g., a service-specific auth
response as per NASREQ AA-Answer [RFC7155], the server MUST include response as per NASREQ AA-Answer [RFC7155], the server MUST include
all Session-Group-Info AVPs as received in the client's request. all Session-Group-Info AVPs as received in the client's request.
In addition to the one or multiple session groups identified in the In addition to the one or multiple session groups identified in the
client's request, the server may decide to assign the new session to client's request, the server may decide to assign the new session to
one or multiple additional groups. In such a case, the server MUST one or multiple additional groups. In such a case, the server MUST
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 AVP added by the server
MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in the MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in the
Session-Group-Control-Vector AVP set. Session-Group-Control-Vector AVP set.
If the Diameter server rejects the client's request for a group If the Diameter server rejects the client's request for a group
assignment, the server sends the response to the client, e.g. a assignment, the server sends the response to the client, e.g., a
service-specific auth response as per NASREQ AA-Answer [RFC7155], and service-specific auth response as per NASREQ AA-Answer [RFC7155], and
MUST include all Session-Group-Info AVPs as received in the client's MUST include all Session-Group-Info AVPs as received in the client'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 accept flag of the Session-Group-Control-Vector AVP. The server MAY accept
the client's request for the identified session but refuse the the client's request for the identified session but refuse the
session's assignment to any session group. The server sends the session's assignment to any session group. The server sends the
response to the client indicating success in the result code. In response to the client indicating success in the result code. In
such case the session is treated as single session without assignment such case the session is treated as single session without assignment
to any session group by the Diameter nodes. to any session group by the Diameter nodes.
If the Diameter server accepts the client's request for a group If the assignment of the session to one or some of the multiple
assignment, but the assignment of the session to one or some of the identified session groups fails, the session group assignment is
multiple identified session groups fails, the session group treated as failure. In such case the session is treated as single
assignment is treated as failure. In such case the session is session without assignment to any session group by the Diameter
treated as single session without assignment to any session group by nodes. The server sends the response to the client and MAY include
the Diameter nodes. The server sends the response to the client and those Session-Group-Info AVPs for which the group assignment failed.
MAY include as information to the client only those Session-Group- The SESSION_GROUP_ALLOCATION_ACTION flag of included Session-Group-
Info AVPs for which the group assignment failed. The Info AVPs MUST be cleared.
SESSION_GROUP_ALLOCATION_ACTION flag of included Session-Group-Info
AVPs MUST be cleared.
If the Diameter server receives a command request from a Diameter If the Diameter server receives a command request from a Diameter
client and the command comprises one or multiple Session-Group-Info client and the command includes a Session-Group-Info AVP which does
AVPs and none of them includes a Session-Group-Id AVP, the server MAY not include a Session-Group-Id AVP, the server MAY decide to assign
decide to assign the session to one or multiple session groups. For the session to one or multiple session groups. For each session
each session group, to which the server assigns the new session, the group, to which the server assigns the new session, the server
server includes a Session-Group-Info AVP with the Session-Group-Id includes a Session-Group-Info AVP with the Session-Group-Id AVP
AVP identifying a session group in the response sent to the client. identifying a session group in the response sent to the client. Each
Each of the Session-Group-Info AVPs included by the server MUST have of the Session-Group-Info AVPs included by the server MUST have the
the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group- SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-
Control-Vector AVP set. Vector AVP set.
If the Diameter server receives a command request from a Diameter If the Diameter server receives a command request from a Diameter
client and the command does not contain any Session-Group-Info AVP, client and the command does not contain any Session-Group-Info AVP,
the server MUST NOT assign the new session to any session group but the server MUST NOT assign the new session to any session group but
treat the request as for a single session. The server MUST NOT treat the request as for a single session. The server MUST NOT
return any Session-Group-Info AVP in the command response. return any Session-Group-Info AVP in the command response.
If the Diameter client receives a response to its previously issued If the Diameter client receives a response to its previously issued
request from the server and the response comprises at least one request from the server and the response includes at least one
Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION
flag of the associated Session-Group-Control-Vector AVP set, the flag of the associated Session-Group-Control-Vector AVP set, the
client MUST add the new session to all session groups as identified client MUST add the new session to all session groups as identified
in the one or multiple Session-Group-Info AVPs. If the Diameter 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 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 the one or multiple Session-Group-info AVPs, the client
MUST terminate the session. The client MAY send a subsequent request MUST terminate the session. The client MAY send 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 assignment of the session to a session group
skipping to change at page 10, line 50 skipping to change at page 10, line 42
the assignment of the session to the one or multiple groups. If the the assignment of the session to the 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
solely the assignment of the session to a session group has been solely 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 single
session without group assignment. session without group assignment.
A Diameter client, which sent a request for session initiation to a A Diameter client, which sent a request for session initiation to a
Diameter server and appended a single or multiple Session-Group-Id Diameter server and appended a single or multiple Session-Group-Id
AVPs but cannot find any Session-Group-Info AVP in the associated AVPs but cannot find any Session-Group-Info AVP in the associated
response from the Diameter server proceeds as if the request was response from the Diameter server proceeds as if the request was
processed for a single session. When the Diameter client is processed for a single session. The Diameter client MUST NOT retry
confident that the Diameter server supports session grouping and to request group assignment for this session, but MAY try to request
group signaling, the Diameter client SHOULD NOT retry to request group assignment for other new sessions.
group assignment for this session, but MAY try to request group
assignment for other new sessions.
4.2.2. Removing a session from a session group 4.2.2. Removing a session from a session group
When a Diameter client decides to remove a session from a particular When a Diameter client decides to remove a session from a particular
session group, the client sends a service-specific re-authorization session group, the client sends a service-specific re-authorization
request to the server and adds one Session-Group-Info AVP to the request to the server and adds one Session-Group-Info AVP to the
request for each session group, from which the client wants to remove request for each session group, from which the client wants to remove
the session. The session, which is to be removed from a group, is the session. The session, which is to be removed from a group, is
identified in the Session-Id AVP of the command request. The identified in the Session-Id AVP of the command request. The
SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-
skipping to change at page 11, line 34 skipping to change at page 11, line 24
adds a single Session-Group-Info AVP to the request which has the adds a single Session-Group-Info AVP to the request which has the
SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id
AVP omitted. The session, which is to be removed from all groups, to AVP omitted. The session, which is to be removed from all groups, to
which the session has been previously assigned, is identified in the which the session has been previously assigned, is identified in the
Session-Id AVP of the command request. Session-Id AVP of the command request.
If the Diameter server receives a request from the client which has If the Diameter server receives a request from the client which has
at least one Session-Group-Info AVP appended with the at least one Session-Group-Info AVP appended with the
SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server MUST remove SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server MUST remove
the session from the session group identified in the associated the session from the session group identified in the associated
Session-Group-Id AVP. If the request comprises at least one Session- Session-Group-Id AVP. If the request includes at least one Session-
Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared
and no Session-Id AVP present, the server MUST remove the session and no Session-Id AVP present, the server MUST remove the session
from all session groups to which the session has been previously from all session groups to which the session has been previously
assigned. The server MUST include in its response to the requesting assigned. The server MUST include in its response to the requesting
client all Session-Group-Id AVPs as received in the request. client all Session-Group-Id AVPs as received in the request.
When the Diameter server decides to remove a session from one or When the Diameter server decides to remove a session from one or
multiple particular session groups or from all session groups to multiple particular session groups or from all session groups to
which the session has been assigned beforehand, the server sends a which the session has been assigned beforehand, the server sends a
Re-Authorization Request (RAR) or a service-specific server-initiated Re-Authorization Request (RAR) or a service-specific server-initiated
skipping to change at page 12, line 12 skipping to change at page 11, line 50
session group, to which the session had been previously assigned. To session group, to which the session had been previously assigned. To
indicate removal of the indicated session from one or multiple indicate removal of the indicated session from one or multiple
session groups, the server sends a service-specific auth response to session groups, the server sends a service-specific auth response to
the client, containing a list of Session-Group-Info AVPs with the the client, containing a list of Session-Group-Info AVPs with the
SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id
AVP identifying the session group, from which the session should be AVP identifying the session group, from which the session should be
removed. The server MAY include to the service-specific auth removed. The server MAY include to the service-specific auth
response a list of Session-Group-Info AVPs with the response a list of Session-Group-Info AVPs with the
SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP
identifying session groups to which the session remains subscribed. identifying session groups to which the session remains subscribed.
In case the server decides to remove the identified session from all 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 auth response at least
one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION
flag cleared and Session-Group-Id AVP absent. flag cleared and Session-Group-Id AVP absent.
4.2.3. Mid-session group assignment modifications 4.2.3. Mid-session group assignment modifications
Either Diameter node (client or server) can modify the group Either Diameter node (client or server) can modify the group
membership of an active Diameter session according to the specified membership of an active Diameter session according to the specified
permission considerations. permission considerations.
skipping to change at page 12, line 46 skipping to change at page 12, line 36
AVP present. When the server received the service-specific re- AVP present. When the server received the service-specific re-
authorization request, it MUST update its locally maintained view of authorization request, it MUST update its locally maintained view of
the session groups for the identified session according to the the session groups for the identified session according to the
appended Session-Group-Info AVPs. The server sends a service- appended Session-Group-Info AVPs. The server sends a service-
specific auth response to the client containing one or multiple specific auth response to the client containing one or multiple
Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag
set and the Session-Group-Id AVP identifying the new session group to set and the Session-Group-Id AVP identifying the new session group to
which the identified session has been assigned. which the identified session has been assigned.
When a Diameter server enforces an update to the assigned groups mid- When a Diameter server enforces an update to the assigned groups mid-
session, it sends a Re-Authorization Request (RAR) message to the session, it sends a Re-Authorization Request (RAR) message or a
client identifying the session, for which the session group lists are service-specific request to the client identifying the session, for
to be updated. The client responds with a Re-Authorization Answer which the session group lists are to be updated. The client responds
(RAA) message. The client subsequently sends a service-specific re- with a Re-Authorization 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 authorization request containing one or multiple Session-Group-Info
AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the
Session-Group-Id AVP identifying the session group to which the Session-Group-Id AVP identifying the session group to which the
session had been previously assigned. The server responds with a session had been previously assigned. The server responds with a
service-specific auth response and includes one or multiple Session- service-specific auth response and includes one or multiple Session-
Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and
the Session-Group-Id AVP identifying the session group, to which the the Session-Group-Id AVP identifying the session group, to which the
identified session is to be assigned. With the same response identified session is to be assigned. With the same response
message, the server may send one or multiple Session-Group-Info AVPs message, the server may send one or multiple Session-Group-Info AVPs
with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the
skipping to change at page 13, line 33 skipping to change at page 13, line 24
Info AVP having the SESSION_GROUP_STATUS_IND flag cleared and the Info AVP having the SESSION_GROUP_STATUS_IND flag cleared and the
Session-Group-Id AVP identifying the session group, which is to be Session-Group-Id AVP identifying the session group, which is to be
deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated
Session-Group-Control-Vector AVP MUST be cleared. Session-Group-Control-Vector AVP MUST be cleared.
4.4. Performing Group Operations 4.4. Performing Group Operations
4.4.1. Sending Group Commands 4.4.1. Sending Group Commands
Either Diameter node (client or server) can request the recipient of Either Diameter node (client or server) can request the recipient of
a request to process an associated command for all sessions being a request to process an associated command for all sessions assigned
assigned to one or multiple groups by identifying these groups in the to one or multiple groups by identifying these groups in the request.
request. The sender of the request appends for each group, to which The sender of the request appends for each group, to which the
the command applies, a Session-Group-Info AVP including the Session- command applies, a Session-Group-Info AVP including the Session-
Group-Id AVP to identify the associated session group. Both, the Group-Id AVP to identify the associated session group. Both, the
SESSION_GROUP_ALLOCATION_ACTION flag as well as the SESSION_GROUP_ALLOCATION_ACTION flag as well as the
SESSION_GROUP_STATUS_IND flag MUST be set. SESSION_GROUP_STATUS_IND flag MUST be set.
If the CCF of the request mandates a Session-Id AVP, the Session-Id If the Command Code Format (CCF) of the request mandates a Session-Id
AVP MUST identify one of the single sessions which is assigned to at AVP, the Session-Id AVP MUST identify one of the single sessions
least one of the groups being identified in the appended Session- which is assigned to at least one of the groups being identified in
Group-Id AVPs. the appended Session-Group-Id AVPs.
The sender of the request MUST indicate to the receiver how multiple The sender of the request MUST indicate to the receiver how multiple
resulting transactions associated with a group command are to be resulting transactions associated with a group command are to be
treated by appending a single instance of a Group-Response-Action treated by appending a single instance of a Group-Response-Action
AVP. When a server sends, as example, a Re-Authorization Request AVP. For example, when a server sends a Re-Authorization Request
(RAR) or a service-specific server-initiated request to the client, (RAR) or a service-specific server-initiated request to the client,
it can indicate to the client whether to process the request, after it indicates to the client to follow the request according to one of
having sent the RAA to the server, with either sending a single RAR three possible procedures. When the server sets the Group-Response-
message for all identified groups (server sets the Group-Response- Action AVP to ALL_GROUPS (1), the client sends a single RAR message
Action AVP to ALL_GROUPS (1)), or sending a single RAR message for for all identified groups. When the server sets the Group-Response-
each identified group individually (server sets the Group-Response- Action AVP to PER_GROUP (2), the client sends a single RAR message
Action AVP to PER_GROUP (1)). The server may also request the client for each identified group individually. When the server sets the
to follow-up with a single RAR message per impacted session (server Group-Response-Action AVP to PER_SESSION (3), the client follows-up
sets the Group-Response-Action AVP to PER_SESSION). In such case, with a single RAR message per impacted session. If a session is
the client sends only one RAR message for an impacted session in case included in more than one of the identified session groups, the
the session is included in more than one of the identified session client sends only one RAR message for that session.
groups.
If the sender sends a request including the Group-Response-Action AVP If the sender sends a request including the Group-Response-Action AVP
set to ALL_GROUPS (1) or PER_GROUP (2), it MUST expect some delay set to ALL_GROUPS (1) or PER_GROUP (2), it has to expect some delay
before receiving the corresponding answer(s) as the answer(s) will before receiving the corresponding answer(s) as the answer(s) will
only be sent back when the request is processed for all the sessions only be sent back when the request is processed for all the sessions
or all the session of a session group. If the process of the request or all the session of a session group. If the process of the request
is delay-sensitive, the sender SHOULD NOT set the Group-Response- is delay-sensitive, the sender SHOULD NOT set the Group-Response-
Action AVP to ALL_GROUPS (1) or PER_GROUP (2). If the answer can be 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 sent before the complete process of the request for all the sessions
or if the request timeout timer is high enough, the sender MAY set or if the request timeout timer is high enough, the sender MAY set
the Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2). the Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2).
If the sender wants the receiver of the request to process the If the sender wants the receiver of the request to process the
skipping to change at page 15, line 14 skipping to change at page 14, line 51
identified in the group command, MUST be deleted according to the identified in the group command, MUST be deleted according to the
procedure described in Section 4.3. procedure described in Section 4.3.
When a Diameter node receives a request to process a command for one When a Diameter node receives a request to process a command for one
or more session groups and the result of processing the command or more session groups and the result of processing the command
succeeds for some sessions identified in one or multiple session succeeds for some sessions identified in one or multiple session
groups, but fails for one or more sessions, the Result-Code AVP in groups, but fails for one or more sessions, the Result-Code AVP in
the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per
Section 7.1.2 of [RFC6733]. Section 7.1.2 of [RFC6733].
In case of limited success, the sessions, for which the processing of In the case of limited success, the sessions, for which the
the group command failed, MUST be identified using a Failed-AVP AVP processing of the group command failed, MUST be identified using a
as per Section 7.5 of [RFC6733]. The sender of the request MUST fall Failed-AVP AVP as per Section 7.5 of [RFC6733]. The sender of the
back to single-session operation for each of the identified sessions, request MUST fall back to single-session operation for each of the
for which the group command failed. In addition, each of these identified sessions, for which the group command failed. In
sessions MUST be removed from all session groups to which the group addition, each of these sessions MUST be removed from all session
command applied. To remove sessions from a session group, the groups to which the group command applied. To remove sessions from a
Diameter client performs the procedure described in Section 4.2.2. session group, the Diameter client performs the procedure described
in Section 4.2.2.
4.4.4. Single-Session Fallback 4.4.4. Single-Session Fallback
Either Diameter node can fall back to single session operation by Either Diameter node can fall back to single session operation by
ignoring and omitting the optional group session-specific AVPs. ignoring and omitting the optional group session-specific AVPs.
Fallback to single-session operation is performed by processing the Fallback to single-session operation is performed by processing the
Diameter command solely for the session identified in the mandatory Diameter command solely for the session identified in the mandatory
Session-Id AVP. In such case, the response to the group command MUST Session-Id AVP. In such case, the response to the group command MUST
NOT identify any group but identify solely the single session for NOT identify any group but identify solely the single session for
which the command has been processed. which the command has been processed.
5. Operation with Proxy Agents 5. Operation with Proxy Agents
In case of a present stateful Proxy Agent between a Diameter client In the case of a present stateful Proxy Agent between a Diameter
and a Diameter server, this specification assumes that the Proxy client and a Diameter server, the Proxy Agent MUST perform the same
Agent is aware of session groups and session group handling. The mechanisms per this specification to advertise session grouping and
Proxy MUST update and maintain consistency of its local session group operations capability towards the client and the server
states as per the result of the group commands which are operated respectively. The Proxy MUST update and maintain consistency of its
between a Diameter client and a server. In such case, the Proxy local session states as per the result of the group commands which
Agent MUST act as a Diameter server in front of the Diameter client are operated between a Diameter client and a server. In such case,
and MUST act as a Diameter client in front of the Diameter server. the Proxy Agent MUST act as a Diameter server in front of the
Therefore, the client and server behavior described in Section 4 Diameter client and MUST act as a Diameter client in front of the
applies respectively to the stateful Proxy Agent. Diameter server. Therefore, the client and server behavior described
in Section 4 applies respectively to the stateful Proxy Agent.
In case a stateful Proxy Agent manipulates session groups, it MUST If a stateful Proxy Agent manipulates session groups, it MUST
maintain consistency of session groups between a client and a server. maintain consistency of session groups between a client and a server.
This applies to a deployment where the Proxy Agent utilizes session This applies to a deployment where the Proxy Agent utilizes session
grouping and performs group operations with, for example, a Diameter grouping and performs group operations with, for example, a Diameter
server, whereas the Diameter client is not aware of session groups. server, whereas the Diameter client is not aware of session groups.
In such case the Proxy Agent must reflect the states associated with In such case the Proxy Agent must reflect the states associated with
the session groups as individual session operations towards the the session groups as individual session operations towards the
client and ensure the client has a consistent view of each session. client and ensure the client has a consistent view of each session.
The same applies to a deployment where all nodes, the Diameter client The same applies to a deployment where all nodes, the Diameter client
and server, as well as the Proxy Agent are group-aware but the Proxy and server, as well as the Proxy Agent are group-aware but the Proxy
Agent manipulates groups, e.g. to adopt different administrative Agent manipulates groups, e.g., to adopt different administrative
policies that apply to the client's domain and the server's domain. policies that apply to the client's domain and the server's domain.
Stateless Proxy Agents do not maintain any session state (only Stateless Proxy Agents do not maintain any session state (only
transaction state are maintained). Consequently, the notion of transaction state are maintained). Consequently, the notion of
session group is transparent for any stateless Proxy Agent present session group is transparent for any stateless Proxy Agent present
between a Diameter client and a Diameter server handling session between a Diameter client and a Diameter server handling session
groups. Session group related AVPs being defined as optional AVP groups. Session group related AVPs being defined as optional AVP are
SHOULD be ignored by stateless Proxy Agents and SHOULD NOT be removed ignored by stateless Proxy Agents and should not be removed from the
from the Diameter commands. If they are removed by the Proxy Agent Diameter commands. If they are removed by the Proxy Agent for any
for any reason, the Diameter client and Diameter server will discover reason, the Diameter client and Diameter server will discover the
the absence the related session group AVPs and will fall back to absence the related session group AVPs and will fall back to single-
single-session processing, as described in Section 4. session processing, as described in Section 4.
6. Commands Formatting 6. Commands Formatting
This document does not specify new Diameter commands to enable group This document does not specify new Diameter commands to enable group
operations, but relies on command extensibility capability provided operations, but relies on command extensibility 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 applying the command to all
sessions associated with the identified group(s). sessions associated with the identified group(s).
skipping to change at page 18, line 37 skipping to change at page 18, line 37
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.
SESSION_GROUP_STATUS_IND (0x00000010) SESSION_GROUP_STATUS_IND (0x00000010)
This flag indicates the status of the session group identified in This flag indicates the status of the session group identified in
the associated Session-Group-Id AVP. The flag is set when the the associated Session-Group-Id AVP. The flag is set when the
identified session group has just been created or is still active. identified session group has just been created or is still active.
If the flag is cleared, the identified session group is deleted If the flag is cleared, the identified session group is deleted
and the associated Session-Group-Id is released. If the Session- and the associated Session-Group-Id is released. If the Session-
Group-Info AVP does not comprise a Session-Group-Id AVP, this flag Group-Info AVP does not include a Session-Group-Id AVP, this flag
is meaningless and MUST be ignored by the receiver. is meaningless and MUST be ignored by the receiver.
7.3. Session-Group-Id AVP 7.3. Session-Group-Id AVP
The Session-Group-Id AVP (AVP Code TBD3) is of type UTF8String and The Session-Group-Id AVP (AVP Code TBD3) is of type UTF8String and
identifies a group of Diameter sessions. identifies a group of Diameter sessions.
The Session-Group-Id MUST be globally and eternally unique, as it is The Session-Group-Id MUST be globally unique. The default format of
meant to uniquely identify a group of Diameter sessions without the Session-Group-id MUST comply to the format recommended for a
reference to any other information. Session-Id, as defined in the section 8.8 of the [RFC6733]. The
<DiameterIdentity> portion of the Session-Group-Id MUST identify the
The default format of the Session-Group-id MUST comply to the format Diameter node, which owns the session group.
recommended for a Session-Id, as defined in the section 8.8 of the
[RFC6733]. The <DiameterIdentity> portion of the Session-Group-Id
MUST identify the Diameter node, which owns the session group.
7.4. Group-Response-Action AVP 7.4. Group-Response-Action AVP
The Group-Response-Action AVP (AVP Code TBD4) is of type Unsigned32 The Group-Response-Action AVP (AVP Code TBD4) is of type Unsigned32
and contains a 32-bit address space representing values indicating and contains a 32-bit address space representing values indicating
how the node SHOULD issue follow up exchanges in response to a how the node SHOULD issue follow up exchanges in response to a
command which impacts multiple sessions. The following values are command which impacts multiple sessions. The following values are
defined by this document: defined by this document:
ALL_GROUPS (1) ALL_GROUPS (1)
skipping to change at page 21, line 16 skipping to change at page 21, line 16
session group management concept. session group management concept.
According to the Diameter base protocol [RFC6733], transport According to the Diameter base protocol [RFC6733], transport
connections between Diameter peers are protected by TLS/TCP, DTLS/ connections between Diameter peers are protected by TLS/TCP, DTLS/
SCTP or alternative security mechanisms that are independent of SCTP or alternative security mechanisms 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 information received from non-adjacent nodes. Any Diameter related 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. The DIME working group is currently working on solutions the server. There is ongoing work on the specification of end-to-end
for providing end-to-end security features. When available, these security features for Diameter. Such features would enable the
features should enable the establishment of trust relationship establishment of trust relationship between non-adjacent nodes and
between non-adjacent nodes and the security required for session the security required for session group management would normally
group management would normally rely on this end-to-end security. rely on this end-to-end security. However, there is no assumption in
However, there is no assumption in this document that such end-to-end this document that such end-to-end security mechanism will be
security mechanism will be available. It is only assume that the available. It is only assumed that the solution defined on this
solution defined on this document relies on the security framework document relies on the security framework provided by the Diameter
provided by the Diameter based protocol. based protocol.
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 server. In such a 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. apply to a client (or a server) apply equally to the Proxy agent.
11. Acknowledgments 11. Acknowledgments
The authors of this document want to thank Ben Campbell and Eric The authors of this document want to thank Ben Campbell and Eric
McMurry for their valuable comments to early versions of this draft. McMurry for their valuable comments to early versions of this draft.
Furthermore, authors thank Steve Donovan and Mark Bales for the Furthermore, authors thank Steve Donovan and Mark Bales for the
thorough review and comments on advanced versions of the WG document, thorough review and comments on advanced versions of the WG document,
which helped a lot to improve this specification. which helped a lot to improve this specification.
12. Normative References 12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012, DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>. <https://www.rfc-editor.org/info/rfc6733>.
[RFC7155] Zorn, G., Ed., "Diameter Network Access Server [RFC7155] Zorn, G., Ed., "Diameter Network Access Server
Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, Application", RFC 7155, DOI 10.17487/RFC7155, April 2014,
<https://www.rfc-editor.org/info/rfc7155>. <https://www.rfc-editor.org/info/rfc7155>.
Appendix A. Session Management -- Exemplary Session State Machine Appendix A. Session Management -- Exemplary Session State Machine
A.1. Use of groups for the Authorization Session State Machine A.1. Use of groups for the Authorization Session State Machine
Section 8.1 in [RFC6733] defines a set of finite state machines, Section 8.1 in [RFC6733] defines a set of finite state machines,
representing the life cycle of Diameter sessions, and which MUST be representing the life cycle of Diameter sessions, and which must be
observed by all Diameter implementations that make use of the observed by all Diameter implementations that make use of the
authentication and/or authorization portion of a Diameter authentication and/or authorization portion of a Diameter
application. This section defines, as example, additional state application. This section defines, as example, additional state
transitions related to the processing of the group commands which may transitions related to the processing of the group commands which may
impact multiple sessions. impact multiple sessions.
The group membership is session state and therefore only those state The group membership is session state and therefore only those state
machines from [RFC6733] in which the server is maintaining session machines from [RFC6733] in which the server is maintaining session
state are relevant in this document. As in [RFC6733], the term state are relevant in this document. As in [RFC6733], the term
Service-Specific below refers to a message defined in a Diameter Service-Specific below refers to a message defined in a Diameter
 End of changes. 58 change blocks. 
204 lines changed or deleted 202 lines changed or added

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